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 Counterexamples 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 private runtime 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.No internal incident queue.

T4Evidence LadderRanks claims from toy demos to public logs to real deployment evidence.No unpublished blind-review material.

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

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

Minimal public commands for the two current open-source fronts:

git clone https://github.com/mmjbds/proof-carrying-action
cd proof-carrying-action
python examples/run_no_credit_repair_demo.py --check
python -m pytest

git clone https://github.com/mmjbds/wisdombench
cd wisdombench
python -m pip install -e .
python -m wisdombench.score --sample data/examples/wisdombench_sample.jsonl
python -m pytest

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.

Open the public counterexample route

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

Anonymous-submission artifacts after review windows, 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.

Near-Term Build

The next public technical assets.

The next technical release should add a clean GitHub path: START_HERE.md, CLAIM_BOUNDARY.md, QUICKSTART_PROOF_ENVELOPE.md, docs/EVIDENCE_LADDER.md, docs/FAILURE_CASE_TEMPLATE.md, and examples/proof_envelope_minimal/.

The website should point to those assets once they are verified. Until then, this page defines the interface and keeps the promise narrow: open enough to verify, private enough to survive.

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.