Live verification: what a receipt's badge does and does not establish

Why it matters

Open the receipt for the newest FOMC brief: ledger entry 951dae65…, signed at 2026-09-16T19:54:18.987753+00:00. Near the top, the page shows either a “Verified” badge or a refusal. A reader who has just seen the badge might ask what it settles. Does it mean Kitalpha has checked the brief and found it correct? Does it mean someone is vouching for it? Neither, and the difference matters. The badge is the result of three checks the page re-runs every time it is opened, each of which a reader can repeat. What those checks establish, and what they leave open, is the whole of this lesson.

The concept

A receipt is the record Kitalpha writes when a brief is published. It carries a content hash, a fixed-length fingerprint computed from the brief’s text so that any change to the text changes the fingerprint; a signature, a value computed over the signed payload with a private key that only the signer holds; the public half of that key; and a list of the sources the brief cites, each with the status its address gave at signing time. The ledger is the public list of these receipts, one page per entry.

Verification is the act of testing a receipt rather than taking it on trust, and the ledger page does it afresh on every view. Three checks run. The key check compares the public key printed on the receipt with the key Kitalpha publishes in a small file at a fixed address; that file lists each signing key, its purpose, who holds it and the period it has been valid. The signature check takes the signed payload, the signature and that public key and asks a piece of arithmetic, the Ed25519 algorithm, whether the three fit together; any change to the payload, or a signature made with a different key, makes the answer no. The source check fetches every cited address again and requires each to answer with a normal successful response. Only when all three pass does the page show “Verified”. If any fails, the page shows a refusal, names the check that failed, and tells machines the same through its status code.

Read together, a pass establishes three things. Origin: the record was signed with Kitalpha’s key. Integrity: the payload is exactly what was signed. Reachability: the sources the brief rests on are still there to be read. None of the three needs a person’s word. The key file is public, the payload and the signature are printed on the receipt, and a source address is a link anyone can open. That is what “live” means here: the verdict is re-derived each time from material a reader can inspect, and the badge is a summary of the checks rather than a promise standing in for them.

What a pass leaves open is whether the brief’s sentences are accurate. A signature binds bytes to a key; it has no view on whether those bytes describe the world correctly, and a source that answers is not thereby a source that was read correctly. That question has a different instrument. Before a brief is published, a checker tests each claim in the draft against the verbatim evidence it cites and records a groundedness figure: the number of claims found supported divided by the number evaluated. That figure sits on the brief page beside the text, and it is part of what gets signed. Verified and grounded are therefore two answers to two questions. A receipt can verify while its brief’s groundedness is below one hundred percent, and a brief could be fully grounded while its receipt refuses because a source went dead.

The timeline below places the four events in a signed record’s life in order. Look for the one row that repeats: the statement was published once, the brief was checked once, the receipt was signed once, and the verification happens again on every view.

Worked example

Take the receipt for the newest FOMC brief, together with the brief page it signs. The receipt prints a content hash beginning eef0adc82fbb…, a public key beginning 49326fb2fc3e…, a signing time of 2026-09-16T19:54:18.987753+00:00, and 1 cited source, the statement at the address the timeline shows. The brief page carries the checker’s verdict, which the record attributes to claude-opus-4-8. The steps below read the two records side by side: how many claims the checker listed, what share of the evaluated claims it found supported, what share it left unsupported, and how many sources the ledger page fetches live on each view.

Read the steps as two separate instruments. The first three figures come from the checker and describe the text: how much of what the brief asserts is supported by the spans it cites. The last figure comes from the receipt and describes the checks: how many addresses the page fetches before it shows a badge. Nothing on the ledger page changes the groundedness, and nothing in the groundedness changes whether the signature verifies. A reader who wants to know whether the record is intact reads the badge; a reader who wants to know how well the text is supported reads the brief’s verdict; and neither figure says whether the source itself is right.

Faded example

Now the second record: the published WPSR brief edition, a weekly petroleum report brief with its own receipt and its own checker verdict. The claim count and the groundedness fraction are given below. Complete the last step: express the groundedness as a percentage, then reveal the answer and compare.

Retrieval check

Mark your confidence before each answer. Every option carries an explanation; read the ones you rejected too.

Your summary