A claims ledger is a file that lists each thing a product promises beside the evidence for it, the date of that evidence, and what it does not cover. Without one, ask a codebase “what does this feature prove?” and the answer is scattered: some tests pass, someone ran it once, and the README implies more than the suite covers. The ledger puts the difference between what the system claims and what it can show in one place a reader can check.
how claims outlive their evidence
Every product makes claims, stated or implied: “the vault preserves the source,” “the relay does not learn the message,” “the proxy never sends your history anywhere else.” Some are verified, some are designed that way, and some are hoped. Written as prose, they all read like the same kind of promise.
Verification status also decays. The test that proved a property last quarter still passes, but the feature grew a new path the test does not reach. The claim stays while its evidence shrinks.
what goes in a ledger
Each entry records what is asserted, how it was checked (test, proof, live probe, or review), on what date, and what the check does not cover. Because the ledger is structured data, an automated check can read it, and a claim with stale or missing evidence fails that check the way a failing test does.
Gobstopper’s assurance ledger is the fullest example. The records in docs/assurance/ state which operations have passed verification, on which platform, and in which verification run, and they list the operations that have not. For instance, the released CLI cannot ask a provider to compact a session, and Gobstopper’s qualification matrix says so where the README might otherwise imply it can. The README links to the ledger, so these limits are part of the public documentation.
GhostGet’s claims register does the same for provider behavior: what each integration verified, against which recorded evidence, and whether a claim holds at install time or was observed live. “It worked when we recorded it” and “it works now” are different claims, and the register says which one applies.
when the ledger pays off
A reviewer asking “is X verified?” gets one line to read instead of a search through history. At release time, the ledger works as the checklist, and anything it does not cover ships named as unverified. When a user reports a problem, the ledger shows whether that behavior was ever claimed to work, which separates a bug from a question of scope.
vhalla’s verify notes are a smaller version of the same file: they record what the proofs and test suites cover, so the product’s claims stay within that evidence.