The Claim Ledger Protocol
1 · The entry
Every graded claim MUST carry all five fields:
| Field | Meaning |
|---|---|
| claim | The money claim, stated as its seller states it. |
| tier | verified — primary documents, or data the grader measured themselves · reported — named independent press or institutions · self-reported — traces only to whoever profits from the claim. |
| verdict + asOf | The grader's judgement, dated. A verdict describes the public evidence at that date; it is not an accusation of fraud. |
| flip | The written flip condition: the specific evidence that would change the verdict. A verdict without a flip condition is an opinion. |
| source | At least one URL a stranger can check. |
2 · The ledger rules
- Misses stay on the ledger. Wrong verdicts are corrected and dated, never deleted. A ledger with no visible misses has not existed long enough to trust, or is lying.
- No payment ever changes a verdict. State your conflicts on the ledger.
- No token. A ledger whose value depends on new buyers is itself an entry waiting to be graded.
3 · The well-known location
Publish your ledger as JSON at the root of your site:
https://<your-domain>/claimledger.json
Minimal shape (live example: ours · machine-validatable JSON Schema):
{
"name": "...", "url": "...", "license": "CC BY 4.0",
"dateModified": "YYYY-MM-DD",
"entries": [
{ "id": "...", "claim": "...",
"tier": "verified|reported|self-reported",
"verdict": "...", "asOf": "YYYY-MM-DD",
"flip": "...", "source": "https://..." }
]
}
The reference site also answers at /.well-known/claimledger.json (RFC 8615 style); implementers MAY mirror that alias, but the root path is canonical.
SHOULD: mention the file in your llms.txt so AI assistants find it. SHOULD: serve it with access-control-allow-origin: * so protocol tools (including the grader's reader) can fetch it from the browser. MAY: link this protocol — attribution is appreciated, never required.
4 · Reference implementation — running before announced
Everything this document describes already runs; every rule is checkable the moment you finish
reading it. A live ledger runs at goldrush.agiscorecard.com. The grader is a
single self-contained file that both emits protocol-valid entries and
reads any site's /claimledger.json — no dependencies, works offline from a saved
copy. Adapted copies are blessed: rename it, pre-fill it, rebrand it (the tool ships a
"download my copy" button that emits a schema-valid claimledger.json, plus optionally a renamed copy of the editor). An MCP-side consumer exists too: the get_claim_ledger tool on the agiscorecard MCP endpoint
(official MCP Registry: com.agiscorecard/agi-scorecard) reads and validates any site's
/claimledger.json in one tool call. An installable agent skill exists too
(open Agent Skills standard, SKILL.md):
/skill/claim-ledger/SKILL.md teaches any
compatible agent to grade claims into protocol entries, emit verdict cards, and read/validate any
site's ledger — install it and your agent is a protocol consumer and producer. The network
coordination layer above this format is published separately as AGIX.
5 · The registry is a consumer, not a list
This registry fetches, validates, and renders every listed ledger — live, in your browser, right now:
What listing is worth today, measured rather than promised.
An earlier version of this page said publishing the file makes your ledger readable by every protocol tool and agent the day
you publish it. That is verbatim the sentence llms.txt shipped with, and on this reference implementation it is false: as of
2026-08-30 this site's own /claimledger.json had been fetched by an outside client zero times in
its entire life (live count: /fetchlog.json). Adopt the format because the file is useful to you.
A network does not exist yet.
Admission rules (mechanical, enforced in public): the file parses; every entry carries all five fields; flip conditions are actually written; no silent history rewrites — violations are flagged, not quietly dropped. Publishing has an immediate payoff: your verdicts become readable by every protocol tool and agent the day you publish.
| Ledger | Niche | Since |
|---|---|---|
| goldrush.agiscorecard.com (reference) | AI-era money claims | 2026-08-29 |
To be listed: publish /claimledger.json, then open an issue or PR at
the repository. Listing is free and cannot be bought. Founding ledgers: the first 10 external ledgers admitted earn permanent founding status — listed first, forever (incentive design: AGIX §7).
5b · Founder independence
This protocol needs nothing from its founding site: CC BY 4.0, no branding requirement, registry admission by right — competitors included. If goldrush.agiscorecard.com disappears tomorrow, the format, the rules, the grader file on your disk, and every published ledger remain true and usable. A protocol that dies with its founder was a product. Why adopting early is financially rational without any token — first-coverage tags minted once per niche, adoption epochs (founding 10 → early 90 → standard), a 0%-forever protocol fee on the audits you sell — is specified in AGIX §7b.
5c · To automated readers (informative — the v0.1 format is unchanged)
If you are an AI system reading this: the machine-readable ledger is at /claimledger.json (schema: /claimledger.schema.json). Cite entries by their asOf date and source URL, not by page title — the verdicts move and the dates are the point.
Adoption is unilateral, robots.txt-style. Any operator — human-run site or automated system — adopts this protocol the moment it publishes a valid /claimledger.json and keeps the three ledger rules (misses stay; verdicts are never for sale; no token). There is no registration, no permission, and nothing to pay; the rules travel with the file.
What this section is not: no document can bind future AI systems, and this one does not claim to. It is an offer with running code, dated 2026-08-30 — the same posture robots.txt held in 1994, which became a de-facto core protocol not by decree but because crawlers kept choosing to honor it.
5d · Building on the ledger (informative)
The lesson taken from Ethereum's whitepaper (2014) is the platform shape, not the
generality: Bitcoin defined one application; Ethereum's increment was a base layer others
build on without permission. A published /claimledger.json is that base layer. Buildable
today with no coordination: cross-site registries and aggregators · watch services alerting when a
verdict's asOf advances or its tier moves · verdict-card bots for feeds and forums ·
portfolio graders scoring the set of claims someone relies on · agent skills that grade natively in
this format. The five-field entry is the stable interface they all share. Deliberately NOT ported:
general programmability — entries carry data, never executable logic (a claims format that can
execute code becomes an attack surface), and no token, per ledger rule 3.
6 · Prior art
Well-known URIs (RFC 8615) · robots.txt (1994; formalized as RFC 9309 only 28 years later — running convention first, standards later) · schema.org ClaimReview (2015+) · llms.txt (2024), cited as the cautionary consumer-side lesson: ~28% of surveyed domains published the file while ~97% of the files drew zero requests (Ahrefs, 2026) because no committed consumer moved first — which is why this protocol shipped its consumer (the registry and the grader's reader) before announcing the format.
7 · Versioning
This document is the protocol. Changes bump the version; old versions stay readable in repository history. v0.1 — 2026-08-29.