Receipt format specification
Decision Keep records use an open, vendor-neutral format so any auditor, regulator or counterparty can verify a receipt without our software, our account, or our trust. This page is the specification.
Format version
dkr-1
The format identifier is part of the signed content hash, so a receipt is provably bound to the format that produced it. It is published on every record and at /docs/spec.
How a receipt is constructed
1. Content hash - SHA-256
A deterministic fingerprint of the canonical decision. Keys are sorted, arrays are order-preserving, and fields with no value are omitted (never coerced to null), so the hash is stable and reproducible by any implementation.
- receipt_id- Public handle used to verify, e.g. RCP-20260710-1A2B3C.
- system / agent / version- Origin platform, model/agent, and version.
- received_at- RFC 3339 timestamp the decision was received.
- payload- The decision content. Send references, not raw PII; only its hash is published.
- parents- Upstream receipt ids - chain of custody for derived decisions.
- AI-governance capture- reference_db_state, actor_id/type, confidence, tokens, risk, routing, human_verifier_id.
- format- Receipt format version (dkr-1). Bound into the content hash.
2. Chain hash - SHA-256
Binds each entry to the one before it: SHA-256(prev_hash | content_hash | receipt_id | org_id). The first entry anchors to the constant decisionkeep-genesis-v1. Altering any prior line breaks the link for every later entry.
3. Signature - Ed25519
The organisation signs the chain hash with its own Ed25519 key. Verification needs only the published public key at /.well-known/record-public-key?org=<id>.
4. Optional trusted time - RFC 3161
An independent timestamp authority anchors exactly when the decision was signed, outside your control and outside ours.
Stability & migration commitment
A receipt is evidence that may be challenged years later, so the format is stabilised:
- • The format is versioned.
dkr-1is the current, frozen specification. - • Any breaking change ships as a new version (
dkr-2, …) with a documented, backward-compatible migration. - • Receipts recorded under an older version remain verifiable forever by the versioned verifier - the API, the public /verify tool, and the offline
scripts/verify-ledger.mjs. - • The verifier and this specification are open. No proprietary format, no vendor lock-in, no account required to check a receipt.
Verify anything, anywhere
Auditors verify a receipt at /verify with no account, or run the offline verifier against the exported ledger and published key. Exit code is non-zero on any failure - hand it to counsel.