← Blog

Receipt, a verifier for the records agents produce

Max Ghenis · September 10, 2026 · 2 min

Sepia illustration of an auditor at a desk holding a signed, stamped record up to the light, with a torn copy on the desk stamped REFUSED.

The Axiom agents write encodings all day. When someone uses an encoding later, they need to know when it was produced, that the producer's key signed it, that it is unchanged since, and that the checks recorded on it are the ones required. Receipt, our new open-source verifier for records produced by agents, answers those questions in one package.

An auditor gives Receipt three things: a published version of a record, an earlier version they already trust, and a short specification they wrote in advance that says what a valid record must carry. Receipt answers three questions. Are the files in this version the ones that were signed and witnessed? Does the journal account for every content file, with nothing missing and nothing extra? Are the checks the producer says ran the ones the specification requires? A record counts as witnessed when an outside timestamp authority the auditor chose in advance has recorded it. The verdict depends on those three inputs, on the keys and timestamp authorities the auditor chose, and on the clock of the machine running the check. Nothing else affects it.

The demo shows the command's real output over Receipt's own signed corpus, eighteen runs in all. If someone edits a published file by hand, its bytes no longer match the hash in the journal, and Receipt refuses. If a release is signed with a key the auditor does not trust, Receipt refuses. If a producer publishes a record without declaring a check the specification requires, such as the compile check, Receipt refuses. If someone regenerates every record from scratch with the original key, Receipt passes it when it has nothing older to compare against, and refuses it against an earlier version it already holds. If the fix goes through the pipeline and is added as a new signed and witnessed release, Receipt passes it.

Receipt does not say which model, agent or person produced a record. It does not judge whether the content is right. A declared check tells Receipt only that the producer says it ran. Receipt confirms that the declared checks are the required ones and stops there.

Before any of this code shipped in Receipt, we ran it side by side with the original verifier from the system it came from, on real records from that system. We fixed the original by hash so it could not drift, and required the same verdict, pass or fail, byte for byte. Those comparisons run as four test suites with 108 cases today, 86 of them verdict comparisons. The auditor writes the keys and timestamp authorities they trust into their own committed code, where a producer cannot change them. Receipt ships the checking; the auditor decides whom to trust. An auditor runs it on a clone with git, openssl and Python. It needs no network, no credentials, and nothing from the producer. Receipt is on PyPI at 0.6.1, with a working paper that lists in one table what each verdict establishes.

Every file our encoder writes comes with a signed manifest. The manifest records the encoder version and commit that produced the file, the model that ran, the hash of the instructions it was given, the hash of the context it was shown, and the hash of the file it wrote. Receipt verifies the manifest's signature, and the encoder refuses to apply a manifest whose signature fails. An encoding therefore traces to the exact instructions and the exact encoder that produced it, and our confidence in an encoding rests on that chain. When an encoding is wrong, the fix goes into the encoder and the file is re-encoded. Every later manifest records the new version, so a fix reaches every future encoding.