The golden corpus

Every claim this toolkit makes is backed by fixtures you can run, and the fixtures ship in the tarball — node_modules/epcis.dev/golden-corpus/ is sitting in your project the moment you install. Each tier carries its expected verdict in its name, so the corpus doubles as a ready-made test suite for your own EPCIS layer: feed a tier through validate, assert the exit code, done.

The tiers

directory	contents	expected verdict
golden-corpus/valid-standard/	the five EPCIS event types as standard 2.0 documents — object, aggregation, transaction, transformation, association	validate exit 0
golden-corpus/valid-superset/	conformant-envelope documents: extension fields (spine:who, envelope fields) under a declared context; --project strips to standard 2.0 and still validates against the pinned schema	validate exit 0, with and without --project
golden-corpus/invalid/	schema-invalid documents — a missing action, a malformed eventTime	validate exit 1, per-path errors
golden-corpus/xml-translation/	EPCIS 1.1/1.2/2.0 XML sources, each beside its expected 2.0 JSON-LD as *.expected.json	translate round-trips clean; diff against the pair
golden-corpus/sequences/	capture-law sequences: benign replay, duplicate content, correction via errorDeclaration, no-partial-acceptance	drive capture and assert the ceremony
golden-corpus/staging-batch3/	seam fixtures: the 856/DESADV expected-output document (856-expected.epcis.json) and the FSMA 204 CTE pair (fsma-receiving-cte.json, tlc-lifecycle.json)	validate exit 0, each

The envelope tier is the conformant-superset discipline made concrete: extension fields ride under a declared JSON-LD context, and project(event) always validates against the pinned official EPCIS 2.0.1 schema — the fixtures prove both halves of that sentence at once.

Proof — one fixture per tier, executed

Real runs against the published epcis.dev@0.1.0:

$ CORPUS=node_modules/epcis.dev/golden-corpus

$ ls $CORPUS/
invalid  sequences  staging-batch3  valid-standard
valid-superset  xml-translation

$ npx epcis.dev validate \
    $CORPUS/valid-standard/object-event-shipping.json
valid	schema=epcis-json-schema.json	version=2.0.1
$ echo $?
0

$ npx epcis.dev validate \
    $CORPUS/valid-superset/object-event-attested-observer.json \
    --project
valid	schema=epcis-json-schema.json	version=2.0.1
$ echo $?
0

$ npx epcis.dev validate \
    $CORPUS/invalid/object-event-missing-action.json
schema-error	/epcisBody/eventList/0	must have required property 'action'
schema-error	/epcisBody/eventList/0	must match "then" schema
schema-error	/	must match "then" schema
invalid	errors=3
$ echo $?
1

$ npx epcis.dev validate $CORPUS/staging-batch3/856-expected.epcis.json
valid	schema=epcis-json-schema.json	version=2.0.1
$ echo $?
0

Every directory the listing prints is in the tier table above — staging-batch3/ included: its fixtures are the transaction-seam and FSMA expected-output documents, and each validates exit 0 against the same pinned schema.

And the translation tier, judged by its shipped pair — the 1.2 source in, the fidelity receipt out:

$ npx epcis.dev translate \
    $CORPUS/xml-translation/object-event-1.2.xml --json \
  | jq '{sourceSchemaVersion, fidelity: .fidelity.roundTripClean}'
{
  "sourceSchemaVersion": "1.2",
  "fidelity": true
}

Using the corpus in your CI

The exit codes are the assertion — no harness required:

for f in node_modules/epcis.dev/golden-corpus/valid-standard/*.json; do
  npx epcis.dev validate "$f" || exit 1
done
for f in node_modules/epcis.dev/golden-corpus/invalid/*.json; do
  npx epcis.dev validate "$f" && exit 1
done

Point the same loop at your own event output before it leaves your pipeline, and the corpus becomes a regression fence: your documents judged by the same pinned schema, the same exits, on every commit.