A Decision Receipt is a signed, replayable record of how a consequential decision was made, created at the moment it happens and independently verifiable afterwards.
It records the policy in force, relevant decision context, the outcome and the integrity information needed to determine later whether the signed record has changed.
A receipt does not prove that the decision was correct, that its inputs were true, that the outcome was fair, or that it was lawful everywhere. It does not prove that a named human personally acted, or that a model followed the rationale it stated.
This is a synthetic demo bundle, signed with the demo key msk_demo_v2. The decision it records never happened and the file carries no tenant data. It is the same JSON envelope the API returns from GET /v1/receipts/:id/bundle — a manifest plus the canonical bytes of every bundled file, so it parses in any verifier that accepts the real thing. Verify it offline against the demo public key published at /.well-known/meshqu-demo-keys.json; demo trust roots are deliberately separate from production ones, so this bundle will not verify against a production key and a production receipt will not verify against this one.
The definition is above, in full. What it implies and does not state is the pair of questions a reader forms straight after reading it: when does the record come into existence, and why is the log an institution already keeps not enough?
At the moment the decision happens — which is the property that makes everything else possible.
A receipt is written when the decision is evaluated — not when a batch job runs, not at the end of the day, and not when someone later asks. The policy in force, the submitted context and the outcome are captured in the same operation that produces the outcome.
The policy snapshot is frozen and its digest bound into the record; the integrity hash is computed over the canonical content; the signature is produced over that hash. From that instant, any later change to the recorded content is detectable by anyone holding the artefact.
A receipt is not amended. A correction, an override or an escalation is its own decision with its own receipt, linked to the first. The sequence is the record — nothing is edited into a tidier version of what happened.
Most institutions already log thoroughly. Logging is not the gap; proving is.
It does not record which version of which policy was in force at that moment, or preserve the inputs the decision was actually evaluated against. Both are usually recoverable — from a deploy history, a config repository, a database that has since been migrated — and recovering them is an act of reconstruction, not retrieval.
Assembling evidence across systems, tickets, approvals and institutional memory takes weeks and yields a narrative that is only as good as the assembler. A challenger can dispute the assembly itself, and often does, because nothing about it is independently checkable.
Append-only storage is a property of the system holding it, so it is only as trustworthy as continued access to that system and to the people who operate it. A signed receipt is checkable by someone with no access to MeshQu, no account, and no reason to take anyone at their word — years after the systems that produced it were replaced.
The rest of this page works through the object itself: what is inside it, who or what can produce one, how a sequence of them holds together, and exactly what verifying one does and does not establish. For the structure of the object and the boundaries around it, see structure, verification and trust boundaries; for the exact field-level contract, see the Receipt Reference.
Hover or focus any field on the receipt to inspect its semantics. Verify and Replay sit beneath as operational capabilities — both run locally and reveal real claim outputs, not network theatre.
Synthetic demo fixture, signed with msk_demo_v2. Generated in the MeshQu monorepo and published here as meshqu-public-demo-2026-08.
Bound into integrity_hash.
The verdict, recorded as one of four discrete values — ALLOW, DENY, REVIEW, ALERT— never free text. This receipt records a decline on a credit application. Everything else on the receipt explains how that verdict came about.
Synthetic demo fixture, signed with msk_demo_v2. Generated in the MeshQu monorepo and published here as meshqu-public-demo-2026-08.
A Decision Receipt is the same object whichever of the three produced the decision. What changes is where the decision boundary sits and what the receipt has available to record — not the shape of the artefact, and not how it is verified.
Human decisions are captured through a policy-derived endpoint rather than inferred from tickets and mail threads afterwards. The submitted context, the policy in force and the outcome are bound together at the moment the person acts, and the resulting receipt is the same object an automated path produces.
An agent asks to do something consequential; the request is evaluated against the policy in force and the outcome is signed. The receipt records what was asked, what was decided and on what basis. Identity is whatever the integrating system submits — an actor id and context fields, bound like all submitted context; MeshQu does not independently establish which model or agent acted. Where a rationale is supplied it is preserved as an assertion by the system that produced it — verification does not, and cannot, establish that a model reasoned its way to the answer it gave.
MeshQu integrates at an existing decision boundary through the API without replacing the underlying workflow, policy engine or operational system. The platform continues to make the decision it already makes; what changes is that the decision now leaves a verifiable record instead of a log line.
Actor attribution reflects what the issuing system asserts. A receipt preserves that attribution and binds it so it cannot be revised afterwards; it does not independently establish that a named human personally acted, or that a model followed the rationale it stated.
A single receipt proves one decision. A chain proves a workflow. Related decisions reference each other in order, so a screening, an escalation, a human review, an override and a final approval read as one governed sequence rather than five unrelated records. Hover any step to inspect its receipt and the continuity from the prior one; verify the chain integrity end-to-end.
Receipts ship inside verification bundles that carry their own manifest, policy snapshot, expected public keys and canonicalization profile — plus optional transparency, chain and evidence artefacts when the decision has them. Every digest below is read from the published artefact, and the download is that artefact unmodified. Replay and verification do not require contacting MeshQu.
Pretty-printed for reading. The digest above is over the canonical single-line bytes as shipped — run sha256sum against the download, not against this view.
All ten sub-claims for this bundle, reported together. No network call.
This is a synthetic demo bundle, signed with the demo key msk_demo_v2. The decision it records never happened and the file carries no tenant data. It is the same JSON envelope the API returns from GET /v1/receipts/:id/bundle — a manifest plus the canonical bytes of every bundled file, so it parses in any verifier that accepts the real thing. Verify it offline against the demo public key published at /.well-known/meshqu-demo-keys.json; demo trust roots are deliberately separate from production ones, so this bundle will not verify against a production key and a production receipt will not verify against this one.
A verifier consumes the bundle and reports a status for every sub-claim it can evaluate. This is the whole of what a passing result asserts — stated here rather than only on /spec, because this is the page people actually read before they form a view of what a receipt is worth.
The integrity hash is recomputed from the canonical receipt body and compared to the one recorded. Any edit to the decision, the submitted context or the bound digests changes it.
An Ed25519 signature over the canonical envelope is checked against trusted key material supplied to the verifier — never against a value carried inside the receipt. The envelope covers the integrity hash, the timestamp and the key identity, so the hash is what ties the signature to the content.
Whichever of the ten sub-claims the bundle supports are reported together: manifest digests, snapshot replay, canonicalization profile, and — where the decision has them — evidence, chain and transparency artefacts. Missing material yields not_applicable, never a soft pass.
Verification runs against the bundle, offline, with no call to MeshQu. The long-form account — including a worked tamper demonstration — is in Verifying a Receipt Offline.
The boundary matters more than the claim. A receipt is strong evidence about how a decision was made and deliberately silent about whether it was the right decision — and a reader who does not know where that line sits will over-read a green result.
A receipt records the policy that was in force and the outcome that followed from it. Whether that policy was the right policy is a question about the institution, not about the artefact.
Submitted context is bound so it cannot be revised afterwards. Binding a value is not the same as attesting that it was accurate when it was captured.
A verified receipt is evidence of how a decision was made. It is not a determination that the decision was lawful in every jurisdiction that might later examine it.
A receipt also does not prove that a named human personally acted, or that a model followed the rationale it stated. Those are attributions the issuing system asserts; the receipt preserves them faithfully and makes no further claim about them.
The receipt becomes real through operational context. The same primitive carries different operational shapes — AML escalation, sanctions screening, AI-assisted review, procurement approval, agent tool invocation, credit decision, compliance attestation. One of these, the credit decision, is the signed fixture inspected above; the rest are illustrations drawn to the same schema and labelled as such.
A velocity threshold tripped and the case went to a human analyst. REVIEW is the verdict the policy produced — it is not a deferred decision, it is the decision, and the receipt records the snapshot and evidence references the analyst was handed.
Inspect, verify, and build against the Decision Receipt object. Verification works offline against the issuer’s public key — the bundle is self-describing and outlives the systems that produced it.
Decision Receipts are portable accountability artifacts, designed to be inspected outside the systems that produced them: open schemas, public-key verification, transparency-log compatibility, evidence manifests. That shape sits comfortably alongside Sigstore, DSSE and in-toto style attestations without claiming conformance to any single specification. The shape is the contract; the bundle is the portable witness.
This is a synthetic demo bundle, signed with the demo key msk_demo_v2. The decision it records never happened and the file carries no tenant data. It is the same JSON envelope the API returns from GET /v1/receipts/:id/bundle — a manifest plus the canonical bytes of every bundled file, so it parses in any verifier that accepts the real thing. Verify it offline against the demo public key published at /.well-known/meshqu-demo-keys.json; demo trust roots are deliberately separate from production ones, so this bundle will not verify against a production key and a production receipt will not verify against this one.
MeshQu uses anonymous analytics (Vercel Web Analytics) to understand which pages are useful. No cookies, no personal data, no advertising trackers. See our privacy notice for the full picture.