A golden corpus has three tiers, and the middle one is the honest one.

31 July 2026 · the launch journal

Every vendor in your architecture review says two things: "we are conformant to EPCIS 2.0" and "we extend it where the standard falls short." The first claim has an official schema to check against. The second is where the claims go to die — because "extends" can mean conformant user extensions the spec itself provides for, or it can mean a private dialect that stopped validating in 2024 and nobody noticed. The instrument that tells those apart is not a slide. It is the shape of the test corpus.

A two-tier corpus — valid fixtures and invalid fixtures — can only check the first claim. To make the second claim checkable, the corpus needs three tiers, and this project's does:

golden-corpus/
  valid-standard/    7 fixtures   pure EPCIS 2.0 — validate exits 0
  valid-envelope/    7 fixtures   the two-grain envelope over the conformant
                                  record — and validate STILL exits 0
  invalid/           2 fixtures   schema-invalid on purpose — validate exits 1,
                                  typed per-path errors
  sequences/         7 fixtures   capture-law sequences: idempotent replay,
                                  corrections via errorDeclaration, no partial
                                  acceptance
  xml-translation/   4 pairs      1.1/1.2/2.0 XML sources + expected 2.0
                                  JSON-LD, gating the translator

The corpus ships in the open repo and inside the npm tarball (node_modules/epcis.dev/golden-corpus/), so the fixtures your acceptance gate runs are the fixtures our CI runs. Same bytes.

Why the middle tier exists.

valid-standard/ proves the easy half: one minimal fixture per event type — object, aggregation, transaction, transformation, association — each passing the pinned official schema. invalid/ proves the suite can fail: a missing action, a malformed eventTime, each producing typed, per-path schema errors and exit 1, so a green run means something.

valid-envelope/ is the honest tier. Every fixture in it carries extension-grain data the core standard has no fields for — the attested observer who, the activity reference, the two-grain performer split — under a declared JSON-LD namespace, exactly per the extension mechanism of EPCIS §6.3/§9.1/§10.1.3. And every one of them is required to validate against the pinned official EPCIS 2.0.1 schema, unmodified. Not "our schema." Not "the official schema plus our patches." The artefact at sha256 0f46ff69… as GS1 published it, pinned on the conformance page. Really run, really today:

$ npx epcis.dev validate golden-corpus/valid-envelope/object-event-attested-observer.json
valid	schema=epcis-json-schema.json	version=2.0.1

That is the whole discipline in one command: extension is always paired with conformance. An extended event that fails the official schema is not an extension, it is a fork — and in this corpus it would be a red build, not a footnote. The tier's name is the claim, and the claim is machine-checked on every commit.

Promotion rules: what earns a fixture its tier.

A corpus you can trust as an acceptance gate needs admission rules as boring as a court's:

• valid-standard: passes the pinned schema; uses CBV vocabulary values, never free text; is minimal — one concept per fixture, so a failure names its cause.
• valid-envelope: everything above, plus extension fields only under the declared namespace, plus the projection rule — strip the namespaced fields and a standard consumer sees a complete, meaningful EPCIS 2.0 event, losslessly. A fixture whose meaning lives only in the extensions is rejected: the envelope carries more truth, never different truth.
• invalid: broken in exactly one declared way, with the expected error path recorded, so the suite asserts the right failure, not just a failure.

Fixture changes ride the same governance as schema pins: by ruling, journaled, never silently. A corpus that quietly rewrites its fixtures to match its implementation is the goalpost-moving failure the harness exists to prevent.

How you use this against any vendor. Including us.

You are the person who has to defend buy-over-build to an architecture review, so take the corpus as the review's instrument — it is deliberately vendor-neutral:

1. Feed valid-standard/ to any candidate repository. All seven admit cleanly, or the conformance conversation is over early.
2. Feed invalid/. Both must be rejected, with errors that name the path. A store that swallows a missing action is not validating; it is hoping.
3. Feed valid-envelope/. This is the discriminating test. A conformant repository must accept them — they are valid EPCIS 2.0 documents; the standard says unknown namespaced fields ride along. A vendor whose "EPCIS support" chokes on lawful extensions has implemented the demo, not the spec.
4. Then invert it: take their extended events and run them through the pinned official schema (npx epcis.dev validate, or POST to /validate on this origin — no key). If their dialect fails the official schema, you have found the fork, and you found it before the contract did.

The translation pairs extend the same idiom to the migration path — a decade of 1.1/1.2 XML in, expected 2.0 JSON-LD out, byte-for-byte — and the sequences/ tier does the same for capture behavior: replay is idempotent, corrections are declared, acceptance is whole-job or nothing.

The corpus is the argument. Clone the repo, run the three tiers, and the words "conformant" and "extended" stop being adjectives in a deck and start being exit codes — which is the only form of vendor claim your review should be accepting this year.