Mian Zhang

Public Release - 2026-06-01

Every public claim needs a state.

A serious claim should not be only a sentence. It should have status, scope, evidence links, boundary notes, downgrade triggers, and attack routes.

claim status scope downgrade
Public Boundaries Claim Table Evidence Map Challenge Route
Boundary ledger card with claim, counterexample, update type, old boundary, new boundary, and artifact requirement.

Ledger

The claim surface must become inspectable.

Yesterday's Evidence Console turned public pages into a control surface. Today focuses on the first control: the Claim Ledger. A public claim is not ready until it can be inspected, attacked, downgraded, or withdrawn.

Claim Ledger v0 records only public claims. It does not mix in private experiments, customer examples, anonymous review material, production logs, or internal orchestration details.

1

claim_id

A stable identifier prevents moving targets when readers challenge a public statement.

2

plain_claim

The claim must be understandable without private context, hidden logs, or unstated assumptions.

3

status

Each claim should be marked as supported, protocol-stage, under review, downgraded, or withdrawn.

4

scope

The ledger should name the task family, data boundary, scale, and environment where the claim applies.

5

evidence_ids

Evidence links should point to public artifacts, registries, demos, papers, or bounded summaries.

6

downgrade_trigger

A claim should say what would shrink it, split it, raise evidence requirements, or withdraw it.

Schema

Claim Ledger v0 fields.

FieldPurposePublic boundaryAttack route
claim_idStable target for inspection.Public identifier only.Moving target check.
plain_claimHuman-readable claim text.No private customer context.Scope too broad.
statusCurrent support level.No implied deployment proof.Status overclaim.
supported_byEvidence IDs and public routes.Public artifacts only.Missing evidence.
does_not_claimExplicit negative boundary.Private system remains private.Boundary leak.
downgrade_triggerWhat would reduce the claim.Counterexamples must be public-safe.Unclear trigger.
A claim card showing what a public claim does and does not prove.

Boundary

A claim should know what it does not prove.

The ledger is valuable only if it prevents overreach. It should not silently turn a protocol note into a deployment claim, a demo into production evidence, or a private observation into a public result.

Each row should therefore carry a negative boundary: what the claim does not say, does not prove, and must not imply.

Challenge

The useful attack is specific.

Pick one public claim and ask whether its scope is too broad, whether its evidence link is missing, whether its status is too strong, or whether its downgrade trigger is unclear.

A valid attack should change the ledger: narrow the claim, add evidence requirements, split the row, mark it under review, or withdraw it.