Skip to content

ClaimBound In 5 Minutes

ClaimBound turns a public claim into a small evidence card.

If there is no evidence card, the statement is still only a claim.

ClaimBound workflow

The Idea

People make public claims about AI systems, models, datasets and methods. A ClaimBound card asks whether one narrow version of that claim was checked under rules fixed before the result.

The card records:

  • the exact claim;
  • the public source;
  • the frozen protocol;
  • the result status;
  • the hashes and sanitized report;
  • the boundary: what the card proves and what it does not prove.

ClaimBound is not a leaderboard, certification authority, newsroom, raw-data archive or blockchain project. It is a thin evidence layer between a claim and a public source.

For AI-assisted work, that same evidence layer can be read as 12 AI Life Rules: AI may assist, but the trusted claim or action still needs a boundary, source, frozen gate, blocked-state policy, audit trail and human review when the action requires it.

One Simple AI Example

Public claim:

Anthropic publishes a public system-card index for its AI models.

ClaimBound question:

Can the official Anthropic system-card page be source-audited by URL, access
date, content type, expected markers and SHA-256?

Card status:

PASSED_UNDER_PROTOCOL

Allowed interpretation:

The public source page passed the documented source-audit gate at access time.

Forbidden interpretation:

This does not prove model safety, model quality, runtime behavior, deployment
readiness or benchmark superiority.

That boundary is the point. A useful card can be green without becoming a broad endorsement.

Statuses In Plain Language

Field Plain meaning
PASSED_UNDER_PROTOCOL It passed, but only under the written rules.
NEGATIVE_RESULT_UNDER_PROTOCOL It was tested and did not pass.
BLOCKED_SOURCE The source, access, metadata or rights boundary blocked a fair result.
INSUFFICIENT_COVERAGE The source exists, but there is not enough usable coverage.
reproduction_level: REPRODUCED_OUTCOME Another run reproduced the gate-level outcome.
reproduction_level: REPRODUCED_OUTCOME_WITH_SOURCE_BYTE_DRIFT The gate-level outcome reproduced, but fresh source bytes differed.

Negative, blocked and drift-limited cards are useful. They stop weak claims from being renamed as successes.

The Workflow

  1. Write a narrow public claim.
  2. Open an evidence request.
  3. Generate a scaffold: protocol draft, playbook, checklist, family ledger and draft card.
  4. Freeze source, claim list, scoring, gate and stop rules before outcome inspection.
  5. Run a manual checklist or deterministic script.
  6. Keep raw payloads, prompt text and transcripts outside the public repo.
  7. Publish a sanitized report with hashes and limitations.
  8. Validate the evidence card JSON.
  9. Validate family and frontier ledgers when related tracks are involved.
  10. Add it to the registry only after validation.

Where To Start

  • Non-developers: start without coding (Windows/macOS/Linux).
  • Browse the evidence cards.
  • Follow getting started for installation and commands.
  • Use uv run claimbound new to create a scaffold.
  • Use uv run claimbound validate-family ... and validate-frontier ... for related R&D tracks.
  • Use uv run claimbound validate-all before publishing cards.