Docs / Concepts

Evidence Record

LiveUpdated September 14, 2026

The Evidence Record is what the layer leaves behind. Everything upstream exists to make it true. A reversal, a dispute packet, a settlement, a reconciliation line, a consent, an attestation, a recurrence and an agent pause are records too, chained to the payment they refer to.

Design#

• One record per attempt. Approved, denied, observed or expired, each request leaves exactly one record.
• Content addressed. The record’s identity is the hash of its canonical bytes (RFC 8785 JSON canonicalization, SHA-256).
• Append only and chained. Each record names the previous record’s hash for the same principal. Records roll into a daily root whose signed checkpoint is published the same day.
• Linked, never edited. What happens after sealing is a new record with chain: { relation, of, of_hash }: reversal_of, dispute_of, settlement_of, reconciliation_of, consent_for, attestation_for, pause_of, merchant_view_of, report_for, recurrence_for, occurrence_of, correction_of. The original bytes never change.
• Time-stamped outside the bytes. An RFC 3161 time-stamp at seal time and the daily-root inclusion proof live in a companion bundle, so they can be renewed across seven years without touching the record.
• Keys snapshotted. Every verification key used at capture is stored with a provenance tag, so a verifier in 2033 needs no live endpoint.
• Trust recorded. Since enruta/0.3 a payment record also carries how the intent was judged (request.intent, decision.judgement), the agent’s identity and assurance level (agent.identity) and the merchant check (payee.identity). The raw anchor evidence and the model’s input and output sit in the bundle, so the verifier can re-hash them.
• Strength labelled. Each record says whether its claim groups are third-party signed, customer attested or self asserted; linked records label their subject the same way. The verifier reports the label; it does not upgrade it.

Two sides, one chain#

When a merchant runs the Accept middleware or reports an order, the seller organization gets its own record of the purchase (kind: agent_order, chain.relation: merchant_view_of) carrying the buyer record’s id and hash. Either side can hand its record to an issuer, an auditor or a dispute vendor, and npx enruta-verify checks both without an Enruta account.

What maps into it#

The core fields are protocol neutral. AP2 mandates, ACP allowances, UCP consent objects, x402 offers and receipts, MPP receipts, card-issuer authorizations and accounting-system exports each map into the same sixteen fields, with the original object kept by digest in protocol. The merchant’s adjustment notifications (UCP, ACP, Adyen, Shopify) map into reversal records.

Where it goes#

• Your auditor. A hash-chained, time-stamped record with an offline verifier makes the test of whether company-supplied electronic information was modified a mechanical one.
• A dispute. The dispute packet is generated from the record: mandate, approval, authorization, the cardholder-recognizable login id, in the formats issuers and dispute vendors accept.
• Your own systems. Records export as JSON with the bundle and the verifier alongside, on demand and on a schedule; the compliance export filters by person, period and kind.

Field by field: Evidence Record schema. How the verifier checks it: Verification.