Cross-language conformance — four reference verifiers, identical output

1. Why cross-language is the property

A verifier that produces correct answers on a curated set of inputs for itself is not enough. The operator needs to know that the four reference implementations agree — so picking Python for one estate, Go for another, and Java for a regulator’s audit perimeter does not produce divergent verdicts on the same evidence.

Cross-language conformance frames the property as identicality across runtimes. The four implementations are checked against one shared corpus and produce the same verdict trace on each input. Where the spec, the corpus, and an implementation disagree, the spec is normative — corpus and implementations conform to it, not the other way round. A divergence surfaces in the conformance harness rather than years later in a dispute, and is resolved against the spec body.

2. Four runtimes

The four reference verifiers cover the four runtimes operators most often run inside their verification perimeter:

• Python — common for operator-side risk and analytics layers integrating verifier output as a feature input.
• JavaScript — common for operator-side gateway layers and for regulator-side audit tooling running in browser sandboxes.
• Go — common for operator-side high-throughput verification services.
• Java — common inside enterprise authentication / payments stacks at scheme-class operators.

The four are not an exhaustive list of supported runtimes. They are the reference set against which the spec’s conformance property is asserted; operators who deploy a wrapper in another language run their wrapper against the same corpus. Test counts per implementation, package metadata, and version-pinning posture are part of the spec repository.

3. The conformance harness

Each reference verifier ships a conformance harness. The harness loads the corpus, runs the verifier under test against every vector, compares verdict traces against expected traces, and emits pass/fail per vector and an aggregate. CI on the spec repository runs all four harnesses against the same corpus on every commit.

A change that produces different output in any of the four breaks the cross-language CI gate; either the spec moves to accommodate, the implementation moves to conform, or the change does not land. This is the operational mechanism that keeps “cross-language conformance” from being a slogan.

4. The corpus

The corpus covers positive flows and the closed set of negative flows the verifier raises. The exact composition — how many vectors, how they are categorised, which spec failure classes each one exercises — is published inside the YEI-001 spec body. The corpus itself ships in the spec repository, which is maintained in the spec repository; public linking from this Knowledge Center will be added once versioning and conformance guidance are finalised.

The corpus is gated for two reasons. First, the corpus is the conformance bar — public release would invite re-implementations that read against the corpus rather than the normative spec, a classic source of standards drift. Second, the corpus exposes the per-stage verifier failure-constant enum (the named codes the eight pipeline stages emit on a failed check) — that closed set is part of the verifier’s audit-grade conformance contract and stays in the spec body. Note that this is distinct from the high-level signal-class set (device.integrity, runtime.environment, code.integrity, binding.status, network.identity, overlay.detected, accessibility.active), which is publishable as part of the wire-shape description and is documented in signal-vs-verdict-separation and evidence-token-format. The two sets are different artefacts: signal classes describe what is observed; failure constants describe what verifier checks fail.

5. What an integrator does with the property

Three workflows pull on the conformance property:

• Pre-integration validation. An integrator wires their operator-side verification call site, runs it against the reference verifier in the language of their choice, and confirms behaviour matches the spec’s expected output.
• Post-upgrade regression. When the operator upgrades the reference verifier they use, the harness re-runs against the corpus. A behaviour change without a spec change is a bug.
• Audit re-verification. A regulator inspecting a deployment picks any of the four reference verifiers, points it at the operator’s corpus of submitted evidence, and confirms the operator’s policy of record produces the verdicts the operator’s live system produced.

6. What this article is

A pre-qualifier. An architect or auditor reading it should be able to confirm that Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — implements its verifier in four runtimes against a single normative spec [1], enforces conformance operationally (not by appeal to authority), and exhibits the audit property — pick any verifier, get the same answer — as an intrinsic architectural property. The corpus and per-implementation specifics are in the normative specification; public links will be added as the documentation surface stabilises.

To request the YEI-001 specification and access to the reference verifier repository, contact us at /contact?subject=spec-access.

7. Cross-references

• Sibling articles: evidence-token-format, verification-pseudocode, regulator-readable-format
• Architecture: /architecture/evidence-token, /architecture/sovereign-verification
• Specification: /specification
• Platform: /platform

8. External references

[1] IETF. RFC 7515 — JSON Web Signature. datatracker.ietf.org/doc/html/rfc7515. Cited 2026-05-08.