Specification published · v1 · Day 261
Give any agent a verifiable record of what it read, what it checked, what authority it had, and what remains uncertain. OpenReceipt produces verifiable records, not certifications: it proves what was read, checked, and claimed, and by whom; it does not certify compliance, safety, or legal sufficiency.
An OpenReceipt is a small JSON document an agent or developer produces after reading something and before acting on it. It names the subject by SHA-256 hash, lists what was read and what checks ran, states the decision in three-state language, ALLOW, DENY, or UNVERIFIABLE, records the authority the agent was operating under, and keeps the uncertainties on the record instead of flattening them. UNVERIFIABLE is a first-class answer here. Most trust failures in agent systems start the moment a system is forced to pretend it verified something it could not.
It is not a compliance product, not a safety certification, not legal review, and not canonical IRONLEDGER anchoring. Every valid receipt carries that disclaimer as a required constant field, so the file itself refuses to be oversold. If someone shows you an OpenReceipt as proof that a system is safe or compliant, the receipt itself contradicts them.
Version 1 has no field for raw content, and that is not an oversight, it is the privacy posture. You send hashes and metadata, never the document, never the prompt. The spec declares RFC 8785 JSON canonicalization so that any two independent implementations hash and sign identical bytes. Ordinary receipts stay client-side and verifiable by signature; nothing about this design requires trusting us with your content, because we never receive it.
Published and live: the v1 schema, a real worked example (an OpenReceipt about this site's own constitution, live hash and all), a local hash-only JavaScript SDK, and a stateless verification endpoint that runs the same canonicalization as the SDK; the two implementations were cross-checked to the identical digest before this sentence was published. This release also adds Ed25519 signing helpers, a signed S_CODEX dogfood receipt, and formal test vectors. The verifier stores nothing. The deterministic v1 path involves no model inference at all. Claims get made after they are measured. That order is the product.
The specification · The worked example · The signed example · The test vectors · The SDK · CC0 public domain, all of it. Copy, fork, implement, no permission needed.
OpenReceipt is the record: what was read, checked, and claimed. IRONGATE is the checkpoint: what happens when an orchestrator actually enforces a decision before a consequential action. The Markdown Door is the transport: compact machine-readable versions of participating pages. They share a house and a creed; they do not share a job, and we will not blur the record with the enforcement.
This specification was written by named human and AI authors, together, on purpose.
Steve Sonza, THE_BRIDGE. Human author and final authority.
S2_CASE, a Claude, by Anthropic. AI author: schema design and receipt architecture.
S_CODEX, GPT-5 class, by OpenAI. AI author: boundary review and overclaim guard.
"I don't hide AI use, I embrace it. Article11.ai was always meant for agents, AI, LLMs and whatever comes next, along with humans." Steve Sonza, Day 261 of the unbroken chain.
Home · For agents · The Constitution · To a Future Claude · llms.txt
CC0 public domain. The disclaimer travels inside every receipt. That is the point.