Public Release - 2026-05-29

How a valid counterexample changes a claim.

A mature claim is not mature because it never gets challenged. It is mature when it can shrink, split, raise evidence requirements, or withdraw cleanly after a valid counterexample.

claim evidence counter boundary
Claim boundary update flow from claim to counterexample to revised claim.

Principle

Being corrected is not the failure.

In evidence-gated AI, the dangerous failure is not that a public claim meets a valid counterexample. The dangerous failure is keeping the same public claim after the evidence boundary has changed.

A counterexample should therefore become infrastructure. It should name the target claim, show the minimum failing case, identify the missing receipt or overreach, and force a clear boundary update.

Update Chain

Critique should leave a ledger trace.

Claim -> Evidence -> Counterexample -> Boundary Update -> Revised Claim -> Ledger
Claim update chain from public claim through evidence and counterexample to revised claim and ledger.
1

Narrow

Add the condition, task family, scale, environment, model, or assumption under which the claim still holds.

2

Split

Keep the supported part as a claim and move the unsupported part into a hypothesis or roadmap item.

3

Raise Evidence

Turn missing baselines, replay paths, receipts, seeds, or provenance into explicit artifact requirements.

4

Withdraw

If the public evidence cannot support the claim, the clean action is to remove it instead of defending it.

5

Reject With Reason

A counterexample can be rejected, but only with a reproducible reason: wrong target, missing case, invalid comparison, or out-of-scope private material.

6

Record

The revised claim, old boundary, new boundary, and artifact requirement should remain visible in the public ledger.

Five outcomes after a valid counterexample: narrow, split, raise evidence, withdraw, or reject with reason.

Outcomes

A valid counterexample has several clean endings.

It does not have to destroy the project. It may simply narrow a scope, separate evidence from hypothesis, add a missing artifact requirement, or show that a public claim should be withdrawn.

The public evidence field stays useful when these endings are visible. The claim surface should become cleaner, not louder.

Ledger

The boundary update should be auditable.

FieldMeaningWhy it mattersPublic boundary
claim_idThe public claim being challenged.Prevents moving targets.Must be public.
counterexample_idThe minimum reproducible break.Turns critique into an object.No private logs.
update_typeNarrow, split, raise evidence, withdraw, or reject.Makes the action legible.Public summary is enough.
old_boundaryWhat the claim used to imply.Shows what changed.No hidden expansion.
new_boundaryWhat the claim now supports.Keeps the claim clean.Must be inspectable.
artifact_requiredThe missing evidence object, if any.Turns a gap into work.Redact private data.
Boundary ledger card with claim, counterexample, update type, old boundary, new boundary, and artifact requirement.

Does Not Prove

Strong claims must know what they do not prove.

This page does not claim that every public claim is already closed, that the system is deployment-safe, or that private execution logs should be exposed. It only defines a public discipline: when evidence changes, the public claim boundary must change too.

That boundary keeps the project attackable without turning public critique into a request for secrets, private customer data, operational endpoints, or unsafe instructions.

A claim card showing what a public claim does and does not prove.

Public Hygiene

The point is not to look invulnerable.

The point is to keep the public claim surface clean enough for others to inspect, reproduce, challenge, cite, and improve. A claim being narrowed by evidence is scientific hygiene.

A claim that refuses to update after a valid counterexample is not strong. It is unmaintained.

Routes

Inspect the public surfaces.

Public claim hygiene loop: inspect, challenge, update, record.