A Receipt Nobody Issues Yet

Almost every conversation about deploying AI inside a regulated company ends at the same wall, and it is not a capability wall. Nobody can verify what an agent did, on whose behalf, with whose consent, under whose policy. That gap is why most AI initiatives in regulated organizations stall in legal review, not in the demo.

In May I wrote a spec for the smallest thing I could think of that would move that wall. It is a receipt. I want to describe it, say where it stands, and be plain that no model provider issues one.

The Inverse Surface

Model providers already vouch for their own side. Confidential inference proves the model ran where it said it ran. Their own tooling increasingly vouches for the client. What is missing is the other direction: a receipt the server hands back to the client. It proves this prompt produced this output on this model at this time, in a form anyone else can check.

The primitive is small on purpose.

Receipt {
  receipt_id     : uuid
  model_id       : string
  prompt_hash    : sha256
  output_hash    : sha256
  issued_at      : iso8601
  key_id         : string
  signature      : ed25519
}

The prompt and the output are hashed, not stored. The content stays private. The verifiability does not. A consumer hashes the prompt and output it was shown, compares them to the receipt, and verifies the signature against the provider's published key set. The result is one of four words: valid, tampered, unknown key, revoked.

Anyone can verify. Nobody can forge. And the provider never has to hold anyone's content to make that true.

Choices I Would Defend

Ed25519 rather than the ECDSA curve most standards-track work reaches for. Deterministic signatures, smaller, no nonce-reuse failure mode. The FIPS and hardware-security-module install base that pushes people toward the other choice is a real constraint for a bank's signing setup. It is not one here.

Hashes, not content. This is the part I think matters most for the regulated case. A receipt that stored prompts would be surveillance infrastructure with an audit label on it. A receipt that stores hashes is useful exactly at audit time and useless for anything else, which is what you want from an audit artifact.

Transport-agnostic. The spec sketches an HTTP mapping, a header the client sets to opt in, a public verify endpoint, a public key set with rotation history. But a provider could bolt it onto whatever it already has.

And the spec versions itself with semver, applied to the specification rather than any implementation. A major bump for a breaking change to the receipt format or verification flow. Minor for additions. Patch for clarifications. That is documentation discipline applied to prose, and I would rather over-specify than watch a spec drift under the code that cites it.

What Exists

A dependency-free reference verifier in Node, using nothing but the built-in crypto module. A machine-readable JSON schema. Four signed reference receipts, one per verification outcome, that seed a conformance suite. You can run the verifier against the valid one and get a valid, swap in the tampered one and get tampered. Those four are real signed receipts, not fixtures, and there is a live endpoint that will verify them.

The contributing guide has one rule I wrote for myself as much as anyone: be skeptical, including of your own proposals. A spec earns its weight by being narrow and durable. Additions have to clear a real bar. Provider-specific concerns belong in the repositories that implement it, not in the spec.

What Does Not

The spec has not been adopted by any model provider. The README says that in its second paragraph, because a spec that hides its adoption count is asking you to trust the wrong thing.

A packaged library is planned and not published. The reference verifier is the implementation for now. I would rather say that than let a package name imply something that is not on the registry.

And there are four open questions I do not have answers to. Multi-turn semantics: one receipt per turn, or a session-scoped bundle. Tool-use scope: does the receipt cover tool inputs and outputs, or only the model's own tokens. Key rotation cadence and the revocation surface. Privacy posture: opt-in by default, opt-out, or per-deployment policy. I listed them at the bottom of the spec as their own section, because knowing what is not decided is part of the spec.

Why I Bothered

I spent twenty years watching good technical work die in a room where the only question was "can you prove what it did." The answer was always some version of no, and the project went into the drawer.

A receipt does not answer that question by itself. But it changes what the question is. With a receipt, "did the model produce this" becomes something anyone with the public key can check. The legal review can move on to the questions that actually need a lawyer.

I am one person with a job board and a draft, which is not the profile that gets standards adopted. I do not expect a provider to pick this up because I wrote it. I expect that someone at a provider is going to need to write something like it sooner or later. I would rather they start from a narrow, versioned draft with its open questions listed than from nothing. If that is you, the repository is public and the issues are open.

-- Justin Higgins. Software Engineer, Midwest. Wrote a receipt format for AI work, and says out loud that nobody issues one yet.

Companion pieces: The Work Looks Like Nothing - why judgment needed somewhere to be recorded.

Reactions, disagreements, war stories: jchigg2000.dev@gmail.com