Technical Layer

Open validation interfaces for reliable AI action.

The public technology layer makes the research inspectable: proof envelopes, action warrants, evidence ladders, counterexample templates, minimal demos, and claim boundaries. It does not expose private customer workflows, live trading logic, or proprietary orchestration.

schema demo counterexample boundary

Runnable Path Architecture Release Boundary

Claim-to-replay evidence contract visual.

Purpose

A community should test the action interface, not clone the operating business.

The public layer has five jobs: show the new direction to serious readers, let newcomers run a small demo, invite skeptics to submit counterexamples, help customers understand high-risk AI action, and protect the private system that turns the research into a service.

This is why the site separates papers, evidence, technology, systems, and press. Papers establish claims. Evidence states what is proven and what is missing. Technology gives runnable verification. Systems explain the product direction. Press is only the distribution layer.

Public Architecture

The inspectable action stack.

These pieces can be documented, partially released, and tested without exposing protected operational logic.

LayerPublic objectWhat it provesPrivate boundary

T0Claim BoundaryStates what the system is and is not allowed to claim.No private customer or trading claims.

T1Proof EnvelopeWraps an action candidate with evidence, assumptions, risks, and missing proofs.No proprietary scoring weights.

T2Action WarrantSeparates recommendation from permission to act.No live execution thresholds.

T3Counterexample TemplateLets critics submit falsifying cases in a structured format.Public counterexample route only.

T4Evidence LadderRanks claims from toy demos to public logs to real deployment evidence.Only public, reusable evidence materials.

T5Minimal DemoShows a local proof-carrying action cycle with no sensitive data.No customer workflows or sensitive instructions.

Runnable Path

What a visitor should be able to do.

The first demo should be small, boring, and hard to fake: create an action candidate, attach evidence, fail a gate, record why it failed, and export a proof envelope. The win is not spectacle. The win is auditable restraint.

1Read the claim boundary

2Run a local proof-envelope demo

3Inspect the action warrant decision

4Submit a counterexample

5Compare against the evidence ladder

Review ledger visual for structured critique and evidence tracking.

Critic Interface

Make objections useful.

A serious community needs an explicit route for attack. Counterexamples should name the claim, the violated assumption, the reproduction steps, the expected failure, and the minimum evidence needed to repair the claim. This turns hostile review into a structured improvement loop.

Counterexample reports should be public when they contain no private data.
Accepted counterexamples should create repair work orders, not defensive prose.
Rejected counterexamples should state which claim boundary they misunderstood.
Repeated counterexamples should become benchmark tasks or evidence-gate tests.

Release Boundary

What to open, delay, or keep private.

This boundary is the core community rule: maximum sincerity at the interface, maximum discipline at the commercial core.

Open Now

Verification Surfaces

Schemas, toy demos, non-sensitive examples, claim boundaries, evidence ladders, contribution templates, and public DOI links.

Open Later

Decision-Safe Artifacts

Public release artifacts, cleaned benchmark adapters, non-sensitive logs, and versioned reproduction notes.

Keep Private

Commercial Closure

Customer memory, live execution traces, proprietary prompts, tool routing, scoring thresholds, finance runtime details, and private partner leads.

Public Build

The current public technical path.

The public GitHub route now carries the clean community path: START_HERE.md, CLAIM_BOUNDARY.md, evidence-ladder notes, counterexample templates, issue routes, and minimal proof-envelope examples as they become public-safe.

The website points readers to those assets through the community page and keeps the promise narrow: open enough to verify, private enough to protect production systems and non-public review material.

Technical Thesis

Reliable AI action is not a model response. It is a claim with evidence, authority, a falsifier, a boundary, and a repair path.

That is the public interface. The private product is the system that keeps producing those proofs while doing real work.