Evidence Verification

An authorization decision is only as trustworthy as the ability of someone other than PayReality to check it. A regulator reviewing a case months later, an insurer with no operational access, or an engineering team investigating an incident shouldn't have to take PayReality's word that a record is accurate: they need to be able to confirm it themselves. What follows covers what's independently verifiable today, and what's planned to make that checking possible without a call back to PayReality's systems at all.

Three evidence layers

What you're verifying grows in three layers. Intent evidence is what was proposed or observed. Authority evidence is why the decision came out the way it did, against which policy and Authority Graph state. Execution evidence is what a trusted destination or execution adapter reported afterward, and whether it was reconciled as matching what was authorized. The first two are produced with every decision; the third only exists once a separately authenticated source reports back. That third layer is EARLY ACCESS, see Runtime API for its current shape.

Signature verification (live)

Every Decision produces a signed Evidence record. Verifying its signature today is an API call, and also a one-click action in the Evidence Portal's UI:

curl -X POST https://api.aisecurewatch.com/v1/evidence/{evidence_id}/verify \
  -H "Authorization: Bearer <token>"

{ "valid": true }

A tampered or corrupted record returns { "valid": false } rather than an error: verification is a check, not an operation that can fail for unrelated reasons.

Evidence export (live)

Search and export evidence from the Evidence Portal scoped to exactly what a specific review needs (by agent, outcome, policy, or time range), rather than granting an auditor broad access to the underlying platform.

Audit workflows (live)

Every field an audit typically needs (the agent, the Principal it acted for, the policy version evaluated, the outcome, and the timestamp) is present on the record itself and searchable in the portal, so an audit doesn't require reconstructing context from application logs elsewhere.

Execution reconciliation EARLY ACCESS

Where a trusted destination or execution adapter has supplied an execution receipt, the decision's record also carries a reconciliation outcome: MATCHED, MISMATCHED, EXECUTION_FAILED, PARTIAL, RECEIPT_MISSING, or INDETERMINATE. A cryptographically authenticated receipt proves what the trusted source reported; it does not independently prove that the underlying business system or real-world event was truthful. This is newer than the rest of what's on this page and not yet part of the stable public contract, see Runtime API for the current shape.

Evidence bundles and offline verification ROADMAP

Today, verifying a record means calling PayReality's own /verify endpoint: accurate, but it means the verifier is trusting PayReality's systems to be reachable and honest at the moment they check. The planned evolution is an exportable bundle: a receipt plus its Merkle inclusion proof plus enough of the key-transparency record to verify entirely offline, without a network call back to PayReality at all. See Authorization Receipts for the receipt format this depends on, and a verification SDK is the natural companion to that, also planned, not started.