Skip to main content
SpecDecision Receiptv2

Decision Receipt Specification

A portable accountability object for consequential decisions.

Decision Receipts bind policy, evidence references, actors, outcomes, and verification metadata into a signed record that can be replayed and independently verified later.

View sample receiptVerify a bundle
Spec at a glance
Schema
receipt/v1 · receipt/v2
Verification
Offline bundle
Canonicalization
meshqu-canonical/v0
Anchoring
Transparency-log compatible
Hashing
SHA-256
Replay
Policy snapshot
Signing
Ed25519
Chains
Supported
§ 01

What this specifies

This page defines the public display and specification model for Decision Receipts. It is not API documentation. It describes the envelope fields, integrity model, verification claims, replay semantics, chain references, evidence boundaries, and trust boundaries that a Decision Receipt makes — and the ones it deliberately does not.

Envelope fields
Integrity model
Verification claims
Replay semantics
Chain references
Evidence boundaries
Trust boundaries
§ 02

Receipt anatomy

Inspect the object. A receipt/v2 envelope, illustratively populated. Field names follow the published TypeScript definitions for receipts and bundles; values are placeholders.The integrity hash, signature, snapshot digest, and evidence manifest digest are part of the signed payload.

receipt.jsonreceipt/v2
  1. {
  2. "receipt_id": "dr_01HJY9F4QB2AJTM3CV8EAR4PD",
  3. "receipt_schema_version": 2,
  4. "issued_at": "2026-05-09T14:21:08.412Z",
  5. "issuer": "tenant_acme",
  6. "decision_type": "vendor_due_diligence",
  7. "outcome": "REVIEW",
  8. "actor": {
  9. "kind": "system",
  10. "id": "fraud-workflow-engine",
  11. "name": "Fraud Workflow Engine"
  12. },
  13. "action": {
  14. "type": "vendor_onboarding_hold",
  15. "reference_id": "VND-88425"
  16. },
  17. "policy_snapshot": {
  18. "snapshot_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  19. "snapshot_digest": "a3f9c1b2…d8e4",
  20. "rules_hash": "7c2a05ee….91bf"
  21. },
  22. "evidence_manifest_digest": "e1c4ab90…7af2",
  23. "evidence_references": [
  24. {
  25. "kind": "document",
  26. "digest": "11b2cd34…aa10",
  27. "custodian": "tenant_acme/legal"
  28. }
  29. ],
  30.  
  31. "integrity_hash": "sha256:9f2a4e0c…7d8e",
  32. "signature": {
  33. "alg": "Ed25519",
  34. "key_id": "tenant_acme/2026-q2",
  35. "value": "6d35019…b8fa"
  36. },
  37. "transparency_anchor": {
  38. "log": "rekor",
  39. "entry_id": "0x9f2a4e0c…",
  40. "inclusion_proof": "….",
  41. "integrated_at": "2026-05-09T14:21:09Z"
  42. },
  43. "chain": {
  44. "chain_id": "chn_01HJY8K…",
  45. "chain_step": 3,
  46. "parent_decision_id": "dr_01HJY8…"
  47. },
  48. "verification": {
  49. "integrity": "valid",
  50. "signature": "valid",
  51. "snapshot_replay": "valid",
  52. "transparency": "valid",
  53. "chain_link": "valid"
  54. }
  55. }
§ 03

Field definitions

Each row records cardinality (required or optional) and source (direct on the receipt, or derived via a documented computation). Where it matters, the row also names what the field proves and what it does not.

receipt_id

Stable identifier for this receipt.

RequiredDirect

Identity (does not prove correctness).

issued_at

When the decision was evaluated and receipt created.

RequiredDirect

Time of decision (not time of truth).

actor

Who or what produced the decision.

RequiredDirect

Attribution (not intent or authority).

policy_snapshot

Frozen policy state used at decision time.

RequiredDirect

Context integrity (not policy quality).

evidence_references

References to evidence relied upon by the decision.

OptionalDirect

Existence & binding (not truth).

integrity_hash

Hash of canonical receipt body.

RequiredDerived

Tamper evidence (not correctness).

signature

Issuer signature over canonical body.

RequiredDirect

Authenticity & integrity.

transparency_anchor

Public log inclusion proof & timestamp.

OptionalDirect

Timing & inclusion (not correctness).

chain

Linkage to surrounding workflow receipts.

OptionalDirect

Continuity (not completeness).

approval_lineage

Approval receipts across policy versions.

OptionalDerived

Lineage integrity (not policy quality).

See all field definitions
§ 04

Verification semantics

A verifier consumes a verification bundle and reports a status per sub-claim. A missing trust root yields not_applicable rather than a soft pass — verification fails closed.

bundle_manifest
valid

Manifest digest recomputes; declared files are present and match recorded SHA-256 entries.

integrity
valid

integrity_hash recomputes from the canonical receipt body.

signature
valid

Ed25519 signature verifies against externally supplied trust root keyed by signature.k_id.

snapshot_replay
valid

Bundled snapshot evaluates to the same outcome and rules hash as the receipt.

evidence
valid

evidence_manifest_digest equals SHA-256 of the bundled canonical evidence manifest.

approval_lineage
n/a

Per-version approval receipts verify against caller-supplied ratifier roots and bound rules hashes.

transparency
valid

Inclusion proof and signed entry timestamp verify against a trusted transparency log key.

chain_link
valid

Linked receipts chain consistently — parent reference and link signatures verify.

chain_seal
n/a

Sealed chain’s closing signature verifies and binds the recorded sequence.

canonicalization
valid

Profile identifier matches and known canonicalization vectors round-trip identically.

Statuses: valid / invalid / not_applicableLearn more about verification
What verification proves
  • The receipt has not been altered.
  • The issuer signature validates.
  • The decision can be replayed against preserved context.
  • Referenced evidence digests match the bundle manifest.
  • Chain references and seals verify where present.
  • Approval lineage verifies where trusted ratifier roots are supplied.
What verification does not prove
  • The original business policy was correct.
  • The underlying evidence was true.
  • The decision was fair by itself.
  • That all disclosure should be unrestricted.
  • That MeshQu must be trusted as a live service.
§ 05

Replay semantics

Same context, same policy snapshot, same outcome. Replay re-runs the preserved decision context against the preserved policy snapshot and checks that the outcome is consistent. Replay validates consistency against preserved context. It does not certify universal truth.

Load snapshot

Load policy snapshot referenced by policy_snapshot_digest.

Resolve evidence

Resolve references using the bundle manifest and verify digests.

Re-evaluate

Run the decision evaluator with the preserved context and snapshot.

Compare outcome

Check that the derived outcome matches the receipt.

§ 06

Evidence model

Bound by digest. Held by the custodian. MeshQu binds evidence through digests, manifests, and references. The institution or custodian retains the underlying evidence. This supports trust without unrestricted disclosure.

Manifest digest
A v2 receipt may bind sha256(canonical(evidence_manifest)). When present, the bundle must ship the manifest; the verifier recomputes the digest and reports evidence.valid on match.
References
Each item in the manifest carries a digest, kind, and optional custodian signature. The payload itself is not required to be in the bundle.
Custodian attestation
Where supplied, a custodian signature on an evidence item is verified against caller-supplied custodian roots. Unknown roots yield a hard failure rather than a skip.
§ 07

Chains

A single receipt proves one decision. A chain proves a workflow. Receipts can reference each other to record an operational sequence — for example: screening → escalation → human review → override → final approval. Chains preserve operational continuity. A chain seal proves completeness and order where present.

  1. Step 01 · systemScreening
  2. Step 02 · systemEscalation
  3. Step 03 · humanHuman review
  4. Step 04 · humanOverride
  5. Step 05 · humanFinal approval
Continuity
Each receipt references its parent_decision_id, recording the operational sequence as it happened.
Ordering
chain_step is monotonically assigned per chain_id; gaps indicate evidence the verifier did not receive.
Seal
When a chain closes, a chain seal proves completeness and ordering. The seal is optional; absence reports as not_applicable.
§ 08

Portability & survivability

A bundle outlives the systems that produced it. Verification bundles are designed to remain useful long after the operational systems that produced them have changed.

Survivability

A verification bundle outlives the systems that produced it.

The bundle is self-describing. It carries the receipt, the canonical policy snapshot, the evidence manifest digest, the public keys it expects, and the canonicalization profile under which every digest was computed. Replay and verification do not require contacting MeshQu.

A bundle remains useful even if
  • The original vendor is gone.
  • The model changed.
  • The workflow platform was replaced.
  • The internal dashboard is unavailable.
  • MeshQu is not online.
Verification still succeedsThe bundle verifies offline against the issuer’s public key. The accountability survives the systems.
§ 09

Standards posture

Decision Receipts are designed to align with emerging practice in runtime accountability, provenance, and verification. The shape of the object — open schemas, public-key verification, transparency-log compatibility, evidence manifests — sits comfortably alongside Sigstore, DSSE, and in-toto style attestations without claiming conformance to any single specification.

  • Open schemasReceipt and bundle types are published as versioned TypeScript definitions.
  • Public-key verificationEd25519 over a canonical envelope. No shared secrets.
  • Transparency-log compatibilityAnchors carry inclusion proofs and signed entry timestamps.
  • Evidence and provenanceManifest digests bind to attested artifacts, not stored payloads.
§ 10

Trust boundaries

The reference is bounded on purpose. These limits keep verification claims honest and prevent the object from being read as more than it is.

Non-claims · what a Decision Receipt does not assert

  • Evidence remains with custodians

    MeshQu does not store evidence payloads by default. Receipts bind digests and references; the underlying artifacts stay in the institution’s systems.

  • Replay is consistency, not correctness

    Replaying the preserved context against the preserved policy snapshot proves outcome consistency. It does not adjudicate whether the original policy was correct or fair.

  • Verification is authenticity and integrity

    The signature, integrity hash, and digests prove that the receipt was issued under a known key and has not been altered. They do not adjudicate business judgement.

  • Disclosure is governed separately

    Verifiability does not imply unrestricted transparency. Receipts can be disclosed selectively under whatever access controls the issuing organisation operates.

  • Actor identity is attested by the issuer

    The actor field reflects what the issuing system asserts. External identity roots can strengthen this; absent those, actor binding is at the issuer’s level of trust.

  • Transparency anchors prove inclusion, not correctness

    A transparency-log entry proves the receipt was witnessed at a particular time. It does not prove that the underlying decision was substantively correct.