Signing a record is easy. A key, a hash, a few dozen lines of code.
Then comes the sentence. "Anyone can verify it."
Anyone can. They run the verifier you wrote, against the format as you understood it. That is one opinion, checked by its author.
My own project has that sentence in its README. It has one verifier, and the verifier lives in the package that writes the receipts.
Two things turn the opinion into evidence: fixed test vectors, and a second verifier written from the document, without importing the first. This post is about both.
1. The verifier that agrees with itself
A typical evidence system ships three things: a format description, code that writes records, and code that verifies them. The last two live in one package and share helpers. The tests sign a record and verify it. They pass.
They would also pass if the description and the code disagreed. Both sides of the test use the same canonicalization function, the same base64 decoder, the same idea of what an integer is. A bug in a shared helper is invisible, because it is applied on both sides.
The person who receives the record is in a worse position. They have the description and a verdict. They have no way to tell whether the two agree, and no fixed inputs to try their own code on.
2. What a second implementation found
This autumn I contributed to TRACE, an open attestation specification for agentic systems. Ten of my pull requests were merged. One of them is a second verifier, in TypeScript, written from the specification and scored against the Python reference by a differential harness: the same records go into both, and the verdicts are compared.
The current run is 1,646 cases. 1,645 are identical. The one that remains is listed in a ledger with its cause.