Authorization Receipts

Why a log isn't enough

Today, every Decision produces a signed record in the Evidence Portal. That's real evidence -- it proves the record wasn't altered after you were shown it. It doesn't, on its own, prove you were shown the complete history: verifying it still means trusting that PayReality's systems remain available, unchanged, and cooperative. That's a reasonable model while an integration is live. It's weaker than what a five-year-later regulatory review, or an insurer underwriting risk without system access, actually needs.

Why receipts exist

An Authorization Receipt is designed to be a self-contained artifact: signed, chained to the receipt before it, and periodically committed to a public, append-only log -- so a verifier who has never had an operational relationship with PayReality can confirm a decision happened, honestly, without calling PayReality's API at all.

Portable trust and independent verification

Two tiers are planned: shallow verification (signature valid, chain intact, included in a published log root -- needs nothing from the customer) and deep verification (the customer discloses the actual intent and policy snapshot; the verifier confirms both hash-match the receipt and that replaying evaluation reproduces the same decision). Minimal disclosure is the default -- a receipt should prove a decision was correct without exposing its sensitive content to every party who might one day need to confirm it happened.

Receipt lifecycle

Created and signed atomically, the instant a Decision is made -- never assembled later from logs. Exported as a self-contained bundle including its inclusion proof. Verified at whichever tier the situation calls for. Retained indefinitely by default. Never edited or deleted: a correction is a new, linked receipt, not a mutation of the original.

The four receipt shapes

Every receipt shares a common envelope. The fields that differ are shown below each example.

{
  "schema_version": "1.0",
  "receipt_id": "rcpt_01J9K3...",
  "receipt_type": "DECISION",
  "issuer": { "platform": "payreality", "tenant_id": "org_9f2b" },
  "issued_at": "2026-08-03T09:14:02.118Z",
  "decision": "ALLOW",
  "agent_id": "agt_8f2b1c",
  "agent_key_thumbprint": "sha256:4c1a...",
  "intent_hash": "sha256:9e3f...",
  "intent_classification": { "action_type": "payment", "risk_tier": "low" },
  "policy_snapshot_hash": "sha256:71bd...",
  "decision_engine_version": "decision-engine@2.4.1",
  "prior_receipt_hash": "sha256:0af2...",
  "signature": "ed25519:...",
  "signing_key_id": "key_2026-q3"
}

{
  "...": "same envelope as above",
  "decision": "DENY",
  "intent_classification": { "action_type": "payment", "risk_tier": "high" }
}

A Deny carries the same fields as an Allow. What differs is only decision and whatever the intent classification reflects -- there is no separate "reason" field disclosed by default, since the reason is recoverable via deep verification against the disclosed policy snapshot.

{
  "...": "same envelope as above",
  "decision": "HUMAN_REVIEW",
  "human_review": { "required_reason_code": "requires_dual_approval" }
}

This receipt is issued the moment escalation happens, and it's not later edited when a human resolves it -- it correctly describes "a human's judgment was required," which remains true forever, independent of what they decided.

{
  "schema_version": "1.0",
  "receipt_id": "rcpt_01J9K4...",
  "receipt_type": "RESOLUTION",
  "issuer": { "platform": "payreality", "tenant_id": "org_9f2b" },
  "issued_at": "2026-08-03T09:47:11.004Z",
  "human_review": {
    "resolved_by_role": "finance_reviewer",
    "resolution": "approved",
    "resolved_at": "2026-08-03T09:47:11Z",
    "resolution_reason_hash": "sha256:c81a...",
    "prior_receipt_id": "rcpt_01J9K3..."
  },
  "signature": "ed25519:...",
  "signing_key_id": "key_2026-q3"
}

A separate, linked receipt, issued when the human actually decides -- immutability is preserved by never touching the original Human Review receipt. Reviewer identity is a role reference by default, not a name, matching minimal disclosure; your own identity system remains where "which specific person" resolves.

Transparency log PLANNED ARCHITECTURE

A periodically published, append-only Merkle log -- modeled on Certificate Transparency, not a blockchain, since there's one issuer and what's needed is public commitment, not decentralized consensus. Once a batch of receipts is committed, altering or omitting one afterward becomes cryptographically detectable rather than merely contractually prohibited. This is the piece that turns "signed" into "independently verifiable" -- without it, verification still means trusting that PayReality showed you everything.

For the full design rationale behind this direction, see Authorization Receipts on the product side, and Evidence Verification for what's actually verifiable today.