Receipts and the Notary

An attestation signed by the party that produced it is still, to a skeptical underwriter, a self-maintained record. This page covers the machinery that makes the evidence hold up when nobody trusts anybody: receipts, minted by an independent Notary, chained so that history cannot be quietly rewritten.

From attestation to receipt

The pipeline has two distinct signing events, and keeping them straight matters:

• The attestation says: this control executed, on this inference, against this baseline. GROUNDED · Labs
• The receipt says: an independent witness saw that attestation exist, at this position in an append-only history. GROUNDED · Labs

The Notary runs on separate infrastructure with its own signing keys, so the witness is independent by construction, not by promise. Receipts are chained into a Merkle log: each entry commits to everything before it, so deleting or altering a historical receipt breaks the chain visibly, and any single receipt can carry an inclusion proof that it belongs to the published history. A signed receipt is immutable — the design invariant is append-only, no exceptions. GROUNDED · Labs

Zero egress: what crosses the trust boundary

Here is the part that disarms the privacy objection before it is raised. The Notary never sees content. Its intake contract is payload-free — essentially {attestation_hash, heartbeat_epoch} in, signed receipt out. GROUNDED · Labs

Stays in the customer’s environment	Crosses to the Notary
Prompts and responses	Hash of the attestation
PII / PHI	Timing epoch
Provider API keys	—
The attestation’s full content	—

Only hashes and signed metadata leave; raw payloads never do. This is the zero-egress posture Volume 1 already summarized as “only hashes cross the trust boundary” — now you know the exact mechanism. It is also why the model works in healthcare at all: a hospital can accept an evidence layer that is structurally incapable of exfiltrating a chart (see why healthcare first). GROUNDED · Labs

“Not records. Receipts.”

The brand line is doing technical work, not just marketing work. A record is something the record-keeper maintains and could alter; its credibility is the keeper’s credibility. A receipt is issued by the other side of a transaction — its credibility survives even if you distrust the holder. Logs are mutable; “configuration is a promise, execution is a fact.” An underwriter pricing a parametric trigger on drift events needs receipt-grade evidence, because the trigger pays real money and every party has an incentive to argue. GROUNDED · Labs

Verification is designed to work offline and without Glacis: the receipt chain, the signatures, and the inclusion proofs can be checked by any third party with open tooling. What exactly a third party can verify, and under what access protocol, is the subject of section 19 — because independence of the verifier is a standards question, not a code question. GROUNDED · Labs

You have been doing this since Act 1

A note for players of the academy game: open your Ledger (the receipts page at /play/ledger/ in the app) and look at what it actually is — an append-only chain of signed entries, one per meaningful event, never edited, never deleted, mistakes corrected by new entries rather than rewrites. You have been keeping attested books since Act 1. The Ledger is OVERT in miniature, and that was not an accident: the pedagogy of this academy and the product it teaches share one spine — never claim what you cannot attest. STABLE

What receipts do not claim

The receipt chain proves that governed inferences were witnessed — it does not prove that all inferences were governed. Coverage of the whole population is a separate, honest measurement (the coverage ratio and the denominator trust ladder, taught in 19-02 and 21-03). Keep the two claims separate and you will never overclaim by accident. GROUNDED · Labs

Next

→ 19-00 What OVERT is

Drill this page →13 bank questions stand behind what you just read. Check it while it’s warm.