knowledge center / theme 06
audit, dispute, and evidence formats
The operational reference — format, verify, dispute, audit, conform.
What the wire format looks like. How a verifier checks it, stage by stage. How a chargeback dispute is composed from signed evidence. Where the boundary between publishable artefact and operator-held corpus sits. Why four reference verifiers across four runtimes produce the same answer on the same input. Five articles for the integrator, the auditor, and the regulator-facing function. Field schema and pseudocode bodies live in the YEI-001 specification.
5 articles · technical reference · normative spec body available on request
The operational reference path runs top-to-bottom across five bands. Each band expands into one article below.
Field schema, pseudocode, and the conformance corpus
The Evidence Token JSON Schema, the verifier pseudocode in RFC 2119 register, the named-failure-class enum, the canonical-form rules, and the cross-language conformance corpus all live inside the YEI-001 specification body — maintained there and available through the spec-access process.
// what is public
· wire shape (JWS-compact · ES256)
· two-profile boundary (Minimal · Standard)
· eight-stage verifier contract
· cross-language conformance property
· standards-alignment grid
// what is gated
· field schema and value enums
· verifier pseudocode bodies
· named-failure-class enum
· conformance corpus + harness
Each row maps an article to the operational band it expands and the canonical artefact it documents.
| # | article | band | artefact |
|---|---|---|---|
| 01 | Evidence Token format — structural shape and the two profiles | format | JWS-compact · ES256 |
| 02 | Verifier pipeline — the eight-step contract | verify | eight-stage contract |
| 03 | Dispute evidence workflow — chargeback investigator path | dispute | operator workflow |
| 04 | Regulator-readable evidence — what is auditable, what stays operator-side | audit | publishable boundary |
| 05 | Cross-language conformance — four reference verifiers, identical output | conform | shared corpus (spec-access) |
- 01 · 2026·04explainer intermediate developer regulatory
Evidence Token format — structural shape and the two profiles
JWS-compact ES256 wire shape with two payload profiles — Minimal for chain-only, Standard for the full signal set. Field schema lives in the YEI-001 spec.
READ →
- 02 · 2026·04explainer intermediate developer architect
Verifier pipeline — the eight-step contract
Eight stages, in order: parse, header, key, signature, chain, freshness, policy, emit. Pseudocode bodies and the failure-class enum sit in the spec.
READ →
- 03 · 2026·04explainer intermediate fraud-team regulatory
Dispute evidence workflow — chargeback investigator path
Case opens, operator queries by tctx, replays the signed sequence, presents three audience-scoped views — investigator, cardholder, regulator.
READ →
- 04 · 2026·05explainer intermediate regulatory
Regulator-readable evidence — what is auditable, what stays operator-side
Schema, pseudocode, four reference verifiers, public spec TOC, abstract test vectors — all publishable. Operator policy and per-deployment corpora stay where they belong.
READ →
- 05 · 2026·05explainer intermediate developer architect
Cross-language conformance — four reference verifiers, identical output
Four reference verifiers across four runtimes share one corpus and produce identical verdicts. The corpus is gated; the property is the public surface.
READ →