Authorization Receipts

What's live today

A Decision's Authorization Receipt is already real and retrievable, through the API and through Decision Detail in the Evidence Portal: the acting Agent and request, the governing policy version and Authority Graph state pinned to the moment the decision was made, any matched trusted facts, the Human Review resolution where one occurred (a separate, linked record, the original decision is never rewritten), Capability Authorization state where one was issued or consumed, integration and Action Mapping provenance for an Adapter-mediated decision, and a cryptographic signature you can check against PayReality's published verification key. What it doesn't yet do is what the rest of this page describes below: be a fully self-contained, offline-verifiable artifact you can check without calling PayReality's API at all. See Evidence Verification for the exact signature-checking mechanics that are real today.

Execution receipts and reconciliation EARLY ACCESS

Don't confuse this with the Authorization Receipt above: an execution receipt is a different artifact, supplied to PayReality after the fact by a separately authenticated destination or trusted execution adapter, reporting what it actually did. PayReality verifies that receipt's linkage back to the original decision and reconciles it against the action it authorized, producing one of: MATCHED, MISMATCHED, EXECUTION_FAILED, PARTIAL, RECEIPT_MISSING, or INDETERMINATE. This closes the loop the Authorization Receipt alone can't: the Authorization Receipt proves PayReality authorized an action; reconciliation records whether the trusted destination reported doing what was authorized.

A cryptographically authenticated execution receipt proves what the trusted source reported. It does not independently prove that the underlying business system or real-world event was truthful. This surface is newer than the rest of what's documented as Live on this page, and not yet part of the stable public contract; see Runtime API for its current shape.

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. A receipt is what lets a third party confirm that the action was authorized by the organization's own policy, not by the AI, and that PayReality evaluated that authorization independently of the agent requesting it. It's the record of that evaluation, not of the AI granting itself permission, and not of PayReality substituting its own judgment for the organization's.

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.