# 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:

```sh
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.

---

**Proof, not adjectives.** This build could not verify the gateway's test suite green, so no sentence on this page claims a passing run — the last verified run is recorded in the repository's own CI, not here. Live on this origin, no key: POST /translate, /validate, /hash. No conformance attestation has ever been issued. The dated ledger is /what-ships-today/.