What this receipt proves —
and what it does not.
A SignedReceipt is process-proof: it attests that a named engine ran over a specific, committed body before that body left the device. It is not result-proof: it does not, and cannot, attest that every piece of personal data in the text was found. Everything on this page follows from that one distinction.
Why the distinction matters
A receipt is a compact, signed statement about an event. Its value comes entirely from being read for what it actually asserts. Read as process-proof — this pipeline ran, on these bytes, with this engine build, and here is the tamper-evident record — it is a strong and genuinely checkable artefact. Read as result-proof — "therefore no personal data was present in what was sent" — it is an overclaim, and one no signature can rescue.
The gap between the two is not an implementation defect to be fixed in a later version. It is structural. Some categories of personal data have a checksum or a fixed format and can be recognised deterministically. Others — a person's name, an organisation, a place, or an individual made identifiable purely by the surrounding context — have neither. Detection of those is model- and dictionary-bound, and therefore best-effort. A receipt attests what the engine did; it cannot attest that there was nothing left to do.
A conformant receipt over a message containing an undetected name is a perfectly valid receipt. That is not a bug in the receipt. It is the boundary of what a receipt is.
What a SignedReceipt does prove
1. The relayed body is the body your device produced
The issuing client commits a hash of the tokenized body before egress and signs it. A relay that alters the body cannot produce a matching signature. So the surrogate-bearing text you can inspect locally is the text that was actually transmitted — nothing was substituted, added or removed in transit or afterwards.
2. Engine identity
The receipt names the engine build and ruleset version that performed the tokenization, by hash. Where the engine is published as an open artifact, the hash is reproducible: you can rebuild the artifact yourself and confirm the digest, rather than trusting a name. A gateway in the path SHOULD attest the declared hash against its own published allowlist rather than accepting the client's self-report — an unrecognised hash is reported honestly as unattested, not silently trusted.
3. Tamper-evidence and ordering
Receipts are signed and chain-linked. Alteration of a receipt, deletion of one from a chain, or reordering within a chain is detectable by any holder of the chain, with no central authority and no cooperation from the issuer.
4. Which detector categories fired
The attestation carries detector categories and counts — never matched values, and never the values' plaintext. This is deliberate: a receipt that carried the matches would itself become a store of the personal data it exists to attest the removal of.
5. Independent, offline verification
Verification requires a public key and the receipt. It does not require an account with the issuer, a live connection to the issuer, or the issuer's continued cooperation or existence. A receipt you hold today remains checkable later.
What a SignedReceipt does not prove
1. Not that every piece of personal data was found
This is the important one. Detection of free-form names, organisations and places is recall-bounded by whatever dictionary or model the engine ships. A receipt over a body that still contains an undetected name is valid, signed, chain-linked — and the name is still there. No receipt should ever be presented as evidence that "no personal data escaped."
2. Not that the surrogate text is harmless
Text can identify a person through context alone, with no identifier of any kind present — a role, a date, a location and an event can be jointly identifying. Detectors do not address this, and receipts do not claim to.
3. Not that tokenization was semantically correct
The receipt attests that a named engine ran and committed a body hash. It does not attest that the engine's decisions were right — that a surrogate was well-chosen, that a classification was accurate, or that a detector's precision trade-offs suit your context.
4. Nothing about what happens after the relay
A receipt witnesses egress. It says nothing about what a recipient — an AI provider, an intermediary, a downstream store — does with the bytes afterwards: whether they are retained, logged, or used for training. Those are questions for the recipient's own commitments, not for this artifact.
5. Nothing about your regulatory position
A receipt is technical evidence about a data flow. It is not a legal conclusion, not a certification, and not a determination of anyone's role or obligations under any data-protection regime. Whether a given flow satisfies a given requirement is a matter for the parties and their advisers. This specification takes no position on it.
Side by side
| Question a reader might ask | Does the receipt answer it? |
|---|---|
| Were these exact bytes the ones that left the device? | Yes — committed body hash, signed pre-egress. |
| Which engine build and ruleset processed them? | Yes — named by hash, reproducible where the artifact is published. |
| Has this record been altered or reordered since? | Yes — signature plus chain link. |
| Which categories of identifier did the engine act on? | Yes — categories and counts, never values. |
| Can I check all of the above without the issuer? | Yes — public key plus receipt, offline. |
| Was every name in the text detected? | No — recall-bounded; out of scope for any receipt. |
| Is the remaining text non-identifying? | No — contextual identification is not addressed. |
| Were the engine's decisions the right ones? | No — the receipt attests that it ran, not that it was correct. |
| What did the recipient do with the bytes? | No — outside the attested event. |
| Does this make a deployment lawful? | No — not a legal conclusion. |
For verifiers: what to do with a receipt
- Check the signature against the issuer's published key, and the chain link against the receipts either side of it. The in-browser verifier does both with no account and no upload to a server.
- Check the engine hash against the issuer's published allowlist — and, if you want the trust anchor to be yours rather than theirs, rebuild the artifact from source and confirm the digest yourself.
- Read the categories, not a verdict. The receipt tells you what fired. It does not tell you what was missed, and a receipt with few categories is not evidence that little personal data was present.
- Ask the issuer for their measurements separately. The question "does this engine actually detect what it claims to?" is answered by published, method-stated measurement — not by a receipt. A receipt is the wrong instrument for it.
For implementers: publish the limits too
Conformance is about the envelope: canonicalization, signing, chain semantics, key discovery. Passing the conformance suite says your receipts are well-formed and verifiable. It says nothing about your detector's recall — and this specification deliberately does not pretend otherwise.
That leaves an obligation on implementers rather than on the format:
- State your detection limits in your own documentation — which categories are deterministic, which are best-effort, and which are known to be evadable.
- Publish measurements with the method and scope attached, so a reader can judge what the number covers. A number without a method is not evidence.
- Measure the bytes that actually leave, not a preview pane and not a unit-test fixture. Capturing the real outgoing request body from the real shipped build is the only measurement that settles what a build sends.
- Publish the defects the measurement finds. A verification process that never finds anything is not a verification process. Reporting a caught-and-closed defect is what makes the clean results credible.
- Never market a receipt as proof that nothing escaped. It is the single most likely misreading of this format, and the one most damaging to it.
A worked example of an implementer doing this — the wire-capture method, the per-surface results, the documented recall limits, and a real defect the method caught and closed — is published at docs.cloakapi.io/security/verification-evidence. It is one implementation's report, not a claim about the format itself; other implementers are encouraged to publish their own and are welcome to link them here via governance.
In one paragraph
A SignedReceipt proves that a specific, named engine processed a specific body on the device and committed to it before it left, in a record nobody can quietly alter afterwards. That is a real and independently checkable guarantee, and it is worth having. It is not a certificate that the text was clean, and anyone presenting it as one — including us, in any document on this site — should be corrected.