What signed audit receipts actually prove (and what they don't)

What the signature actually guarantees

A signed receipt under the ChainChoice format provides five specific cryptographic guarantees.

First: the receipt content has not been altered since signing. The signature is computed over a canonical serialisation of the receipt body. Any change to that body — even a single character — invalidates the signature. A reader who fetches the receipt and verifies the signature against the published public key knows that the bytes they received match the bytes that were signed.

Second: the signing party controlled the private key at the time of signing. The signature can only be produced by the holder of the private key corresponding to the published public key. If the published public key is verifiably ChainChoice's (via the JWKS endpoint and the trust anchoring), the signature proves that ChainChoice signed the content.

Third: the receipt ID is content-addressed. Identical inputs produce identical receipt IDs deterministically. Two readers computing the receipt ID independently from the same input data will arrive at the same ID. This makes the receipt referenceable by content rather than by mutable URL.

Fourth: the timestamp is committed. The signed content includes the receipt creation timestamp. A reader knows the receipt was signed at that time — not retroactively created to look older.

Fifth: the input that produced the recommendation is committed. The receipt binds the input data (the question, the user profile, the catalog state hash) to the output (the recommendation). A reader can verify that the recommendation was actually produced from the inputs they see in the receipt.

What the signature does not guarantee

These are equally important, and rarely stated honestly by platforms claiming signed-receipt architecture.

First: the signature does not prove the methodology was correct. The receipt cryptographically commits to the methodology version used. If the methodology itself is flawed — biased weights, incorrect data, sloppy normalisation — the signature does not detect or correct that. A receipt with a bad methodology is still a verifiable receipt of a bad recommendation.

Second: the signature does not prove the input data was accurate. The receipt commits to the input data hash. If the input data (the provider catalog state, the regulatory status determinations, the fee inputs) contained errors at signing time, those errors are signed in. The signature ensures nobody can later alter the input, but does not detect errors that existed at signing.

Third: the signature does not prove the recommendation was useful for the reader. A receipt can be cryptographically perfect and editorially wrong. The signature confirms what was recommended; it does not confirm whether the recommendation served the reader's actual interest.

Fourth: the signature does not prove non-recommendation. The receipt commits to the recommendations made; it does not commit to the recommendations not made. A provider absent from a "top 5" recommendation is not necessarily absent because of failure on the merits — the receipt does not tell you that story.

Fifth: the signature does not prove that the rest of the platform behaves consistently with the receipt. A receipt is a snapshot of one recommendation at one time. The platform's broader behaviour — which providers it features prominently elsewhere, which advertisers it accepts, which content it pushes on other surfaces — is not bound by the receipt.

Why the distinction matters

The honest distinction matters because the marketing of signed-receipt platforms often blurs it. A platform that says "every recommendation is cryptographically signed" is making a true claim that nonetheless says nothing about the quality of the recommendation.

The useful framing is: signed receipts are a foundation for editorial integrity, not a substitute for it. They make some claims verifiable that would otherwise be unverifiable. They do not make all claims verifiable, and they specifically do not make the deepest claims — methodology quality, data accuracy, editorial judgment — verifiable from the receipt alone.

A reader evaluating a "signed receipt" platform should ask: yes the receipt is signed, but is the methodology that produced it publicly documented? Are the inputs that fed into it externally verifiable? Are corrections and revisions themselves committed as receipts? Is the wider editorial behaviour consistent with the receipt-based claims?

Without positive answers to those questions, signed receipts are cryptographic theatre. With them, they become a meaningful trust layer.

How ChainChoice handles the distinction

We try to be specific about the boundary. Every receipt links to the methodology version it used; the methodology is itself content-addressed and signed; corrections to the methodology produce new signed receipts that supersede the old ones in a continuously verifiable chain. The input catalog state is itself committed in a separate chain of signed snapshots.

This means a reader can audit not just the receipt but the methodology that produced it, the catalog state that fed it, and the history of corrections that have been applied. The receipt is the entry point to the audit trail, not a substitute for it.

We also try not to over-claim. The receipt does not prove that our methodology is correct. It proves that the methodology we used is the one we published, that the recommendation we gave is the one we signed, and that the input we used is the one we committed. The reader still has to evaluate whether the methodology is sound. We make that evaluation as easy as possible by publishing the methodology in full, with versioning and a public changelog. But the evaluation is the reader's, not ours.