Authorization Receipts
A decision's Evidence, authority, and provenance, packaged into one shareable, human-readable view, including the reconciled execution outcome where a trusted destination has reported back. A more advanced, fully portable version, independently verifiable without access to PayReality's own systems, is the direction we're building toward next.
A real Authorization Receipt is live in the product today: every decision's receipt, including actor, request, governing policy version, matched trusted facts, the human review resolution where one occurred (kept as its own linked record, never overwriting the original decision), Capability Authorization state where one was issued or consumed, integration and Action Mapping provenance for an Adapter-mediated decision, the reconciled execution outcome where a trusted destination has reported back, and cryptographic signature, is retrievable through the API and through Decision Detail in the Evidence Portal, assembled from the same signed Evidence and historical policy binding described below. It correctly reports the policy version that actually governed a decision even after the organization has since deployed newer versions, and tampering with the underlying record is detectable.
Today's Receipt is verified against PayReality's own signing infrastructure through the platform's API. What's still ahead is the portable, offline, third-party-independent version: a self-contained artifact a verifier can check entirely on their own, without querying PayReality's live systems at all. The rest of this page describes what we're designing toward for that specific step. For the current receipt shape and what's planned beyond it, see Authorization Receipts in the Developers section.
A signed database row is not a portable proof
Today, every Runtime Authority decision produces signed evidence inside the Evidence Portal. That proves a record wasn't altered after you were shown it. It doesn't, by itself, prove you were shown the complete and honest history: verifying it still means trusting that PayReality's systems remain available, unchanged, and cooperative, indefinitely.
That's a reasonable trust model while an integration is live and the relationship is operational. It's a weaker one than a five-year-later regulatory review, an insurer underwriting risk without system access, or an enterprise proving compliance to its own auditors actually needs.
What we're designing toward
Portable by construction
A receipt is a self-contained artifact, not a database row. Verifying one won't require querying PayReality's live systems.
Cryptographic integrity
Every receipt is signed. Tampering with any field after issuance is detectable without trusting the platform that issued it.
Independent verification
The goal is a verifier who never has an operational relationship with PayReality (an auditor, an insurer, a regulator) being able to confirm a decision happened, honestly, on their own.
Minimal disclosure
A receipt should prove a decision was made correctly without necessarily exposing its sensitive content to every party who might one day need to confirm it happened.
Verification without an operational relationship
Regulators
Examining a decision years after the fact, without depending on PayReality remaining operational, unchanged, or cooperative.
Insurers
Assessing AI-operational risk from a portable artifact, without requiring operational access to a customer's PayReality tenant.
Enterprise customers
Proving to their own auditors and boards that a specific AI-initiated action was authorized under their governance, without PayReality as a required intermediary.
What a receipt proves about execution, and what it doesn't
An Authorization Receipt always proves that a specific action was authorized, under the exact policy and authority in force at the time. When a separately authenticated destination, or a trusted execution adapter acting on its behalf, reports back what happened, PayReality verifies that report's linkage to the original authorization and reconciles it against what was actually authorized. The outcome becomes part of the receipt:
What a receipt won't claim: a cryptographically authenticated execution report proves what the trusted source reported, not that the underlying business system or real-world event was truthful. And reconciliation only runs where a receipt is actually supplied; where none ever arrives, the outcome stays RECEIPT_MISSING, never a silent assumption of success.
Building toward this and want early input?
If independent verification of AI authorization decisions matters to your compliance or risk function, we want to hear what "verified" needs to mean for you.