Evidence Record

The Evidence Record is what the layer leaves behind. Everything upstream exists to make it true.

Design

• One record per attempt. Approved, denied 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 customer. Records roll into a daily root whose signed checkpoint is published the same day.
• Time-stamped outside the bytes. An RFC 3161 time-stamp at seal time, three further authorities and an OpenTimestamps anchor through the daily root. Time-stamps, inclusion proofs and renewals 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.
• Strength labelled. Each record says whether its core claims are third-party signed, customer attested or self asserted. The verifier reports the label; it does not upgrade it.

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 finance-system exports each map into the same sixteen fields, with the original object kept by digest in protocol.

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 mandate, the approval and the authorization in one file, readable by a merchant, an issuer or a platform without an Enruta account.
• Your own systems. Records export as JSON with the bundle and the verifier alongside, on demand and on a schedule.

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