Data with receipts: what a provenance receipt proves, and what it cannot

"Signed" gets used as a synonym for "true." It is not. A provenance receipt proves exactly two things, and it is worth naming them, because selling the third is how trust gets burned.

What a receipt proves

Attribution. A specific key recorded this. The name on the observation is real and cannot be swapped later.

Integrity. The bytes have not changed since they were signed. Edit one character and the signature fails.

What a receipt does not prove

Correctness. You can sign a false statement perfectly. The math says nothing about whether the claim matches the world.

This matters because the value of provenance is in the first two, stated plainly. If a vendor tells you a signature means you no longer need to trust the source, walk away. Signing is added trust. It gives you a name to hold accountable and a value you can re-check, on top of the work of checking the source, never instead of it.

A receipt is structured so anyone can run the check. It names the action, what went in, what came out, when, and who signed it. It links to its parent, so a value can be traced from a final number back through every transformation to the raw source. That chain is the point. A single signature on a final answer tells you little; a chain tells you where a number came from and lets you stop at any step you doubt.

The test of a provenance system

Can a third party, with nothing but your published keys, confirm a receipt in their own browser, offline, without calling your servers? If the verification has to run through the vendor's infrastructure, it proves nothing about the vendor's infrastructure.

DRM3 publishes data with receipts on exactly this model: Ed25519 signatures, chainable receipts, and verification anyone can run against public keys.