Decision Receipt

Every decision the prototype gateway makes can produce a Decision Receipt. The durable, hosted-docs claim is the platform veto.receipt/1 shape described in Decision receipts and the Receipts API.

Use the platform receipt fields for any new audit work:

Shape

{
  "version": "veto.receipt/1",
  "receipt_id": "rcp_01hy2z...",
  "organization_id": "org_123",
  "project_id": "proj_123",
  "decision_id": "dec_123",
  "agent_id": "agent_finance_bot",
  "tool_name": "meow.pay",
  "decision": "allow",
  "reason_code": "consumed",
  "reason_detail": "MCP tools/call; upstream=mock",
  "argument_hash": "sha256:...",
  "result_hash": "sha256:...",
  "policy_hash": "ac3f...",
  "timestamp": "2026-04-21T14:03:24Z",
  "previous_receipt_hash": "sha256:...",
  "merkle_root": "sha256:..."
}

Genesis

The first receipt for an entity has:

previous_receipt_hash = sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

That's SHA-256 of the empty byte string, the canonical genesis anchor used by the current protocol verifier.

Chain verification

Use veto-receipt-protocol for current offline verification. The verifier checks protocol shape, hash-link continuity through previous_receipt_hash, timestamp ordering, and protocol root continuity.

Export

# NDJSON export for audit archive:
curl http://localhost:3005/v1/receipts/ent_acme_llc \
  | jq -c '.receipts[].payload' > receipts-$(date +%s).ndjson

# Verify offline with veto-receipt-protocol.

What binds into the hash

Every field in the receipt payload is included in the canonical bytes that get hashed. That means any mutation breaks the chain at that row and every row after.

What does NOT bind into the hash

• The storage row's stored_at (wall-clock when the SQLite write happened)
• The HTTP response envelope wrapper
• Server-side indices (chain_index)

These exist for operational ergonomics but are derived, not authoritative.