# Evidence Record

One sealed, content-addressed file per payment attempt and per supporting object, chained together and verifiable offline for years.

Status: Live · Updated: 2026-09-14
Source: https://enruta.ai/docs/evidence-record

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.

(Figure: sealchain)

## 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](https://enruta.ai/docs/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](https://enruta.ai/docs/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](https://enruta.ai/docs/compliance-export) filters by person, period and kind.

Field by field: [Evidence Record schema](https://enruta.ai/docs/schema). How the verifier checks it: [Verification](https://enruta.ai/docs/verification).