Knowledge Center / Audit, dispute, and evidence formats / audit + evidence formats · 2026·04
Verifier pipeline — the eight-step contract
The verifier pipeline is the operator's contract with the wire format. Eight stages, in order, each with a defined failure class. The shape of the contract is public — what each stage does, why it sits in this order, what it provides to the next stage. The pseudocode bodies, the named failure constants, and the implementation notes live inside the YEI-001 spec body; public linking from this Knowledge Center is being introduced progressively, and access can be requested directly.
1. Why an eight-step contract
Every operator-side verifier — whether the operator runs the reference Python implementation, the JavaScript one, or wraps it behind a microservice — traverses the same eight stages in the same order. The contract is what makes verifiers interchangeable: the operator can swap implementations without behavioural drift, the regulator can replay a corpus against any of them and get the same answer, an audit can compare an operator’s deployment against the reference behaviour without having to interpret an idiosyncratic implementation.
The order of the eight stages is also load-bearing. A signature check before a key resolution, or a chain check before a signature check, would let bad inputs do unnecessary work (and, in live online verifier deployments, leak state through error timing — for offline regulator replay this is a non-issue). The normative ordering is set by YEI-001 §6; reference verifiers MUST [1] traverse it as written.
2. The eight stages
01 — parse
The verifier decodes the JWS-compact wire form into header, payload, and signature parts. Inputs that are not three base64url-encoded segments separated by dots are rejected at this stage — before any cryptographic work. Anything malformed returns a defined failure class.
02 — validate header
The verifier checks that the header declares the algorithm and
key reference shape the spec requires. Headers that ask for an
unsupported algorithm, omit the key reference, or carry a typ
parameter the spec does not permit are rejected. (RFC 7515 §4.1.9
makes typ OPTIONAL; YEI-001 §4 sets the EEI-specific posture on
which typ values are accepted.)
03 — resolve key
The key reference is looked up in the operator’s public-key
registry — populated at device bootstrap (see
/architecture/zero-trust-bootstrap).
A reference that does not resolve is rejected. The operator’s
registry is the trust anchor; YinkoShield is not contacted at
this step.
04 — verify signature
The verifier runs the cryptographic check against the resolved
public key. The signing input per RFC 7515 [2] §5.1 is the
on-the-wire encoded header and payload joined by a dot —
base64url(header) "." base64url(payload) — verified as bytes.
Implementations that decode and re-serialise the payload before
verifying are wrong: re-serialisation is the classic JWS verifier
bug, and the spec’s verifier pseudocode (YEI-001 §6.4)
explicitly forbids it. There is no JSON-canonicalisation step
on the verifier side; cross-implementation conformance is
maintained by all reference verifiers operating on the same
wire bytes.
05 — check chain
The verifier confirms ledger continuity using the structural
invariants documented in
forward-chaining:
predecessor link, sequence position, boot epoch. The check is
local to the submission — no clock, no cross-operator
coordination. A break is named to a specific position so
downstream tooling can attribute it.
06 — check freshness
Freshness is operator policy. EEI defines the mechanism (the
verifier reads an issued-at value the Trusted Runtime Primitive
(TRP) emits and the device’s hardware-backed signing key signs
inside the JWS-compact envelope, per
self-signing-devices)
and leaves the threshold to the operator. Many operators run
two windows — a short live-decision window and a longer
dispute-retrieval window — by passing different policy snapshots
to different call sites.
07 — match policy inputs
The verifier extracts the structured signal payload (categories
described in
evidence-token-format)
and prepares the verdict-input record the operator’s downstream
policy engine consumes.
08 — emit verdict input
The verdict input is now available to authentication, fraud
scoring, AML, and dispute systems — the composition surface
covered in
host-side-correlation.
3. Failure modes
Stages 01 through 07 each raise one of a closed set of named failure classes when their check does not pass — stages 01–06 on structural checks (parse, header, key, signature, chain, freshness) and stage 07 on operator-policy mismatch. The closed-set property is what makes audit possible: an operator’s verdict trace cites named failures the auditor can map back to spec sections without ambiguity. The named failure constants themselves are defined in the spec body (YEI-001); reference verifiers MUST raise exactly one named failure per stage and MUST NOT silently demote. Stage 08 — emit — does not raise; it returns the verdict input.
4. What the pseudocode contract is for
The full RFC 2119-register pseudocode for each stage lives in YEI-001 §6 and ships alongside the four reference verifiers in the spec repository. The pseudocode is the cross-implementation contract: every reference verifier behaves identically because each one implements the same pseudocode. The pseudocode is maintained in YEI-001 rather than duplicated in this explanatory article, so the normative contract, reference verifiers, and conformance corpus remain version-aligned. This article is non-normative.
To request the YEI-001 specification, contact us at
/contact?subject=spec-access.
5. What this article is
The contract — eight stages, fixed order, defined failure classes — is the operator-readable shape of the verifier. An integrator confirms the stages match their integration plan; an auditor confirms the stages match the verdict trace they read. The deeper ground (per-stage failure-constant enum, implementation notes) sits in the spec body where implementations and audit reviewers see it together. The contract is the public hinge between the wire shape published by Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — and the operator’s verification deployment.
6. Cross-references
- Sibling articles:
evidence-token-format,cross-language-test-vectors,regulator-readable-format - Architecture:
/architecture/evidence-token,/architecture/sovereign-verification - Specification:
/specification
7. External references
[1] IETF. RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels. datatracker.ietf.org/doc/html/rfc2119. Cited 2026-04-22.
[2] IETF. RFC 7515 — JSON Web Signature. datatracker.ietf.org/doc/html/rfc7515. Cited 2026-04-22.