Conformant is a digest
you can check.
Every document is validated against the official GS1 EPCIS 2.0.1 JSON schema — pinned by sha256, precompiled, eval-free — so “conformant” is a digest you can recompute, not a word we chose. The pins below are read from the committed EPCIS 2.0.1 provenance file at build time; if they ever drift from the repository, this page is wrong and that is a reportable defect.
Check it from here: POST /validate on this origin takes any EPCIS 2.0 document or event and answers with the verdict and per-path errors against the pinned schema — no key, no account. No conformance attestation has ever been issued, by us or about us, and no sentence on this page implies one exists. A signed run requires a hosted registrar and a named human Registrar, and the registry code refuses unsigned publication by construction.
The pins.
GS1's normative artefacts are vendored and pinned; pins change only by journaled human ruling, and pnpm verify:pins re-checks the digests in CI. Retrieve the same artefacts from ref.gs1.org and hash them yourself — that is the point of publishing this table.
| artefact | role | sha256 | retrieved |
|---|---|---|---|
| openapi.json | REST binding shapes (Capture + Query interfaces) | 3d33792c520d7a7a1d080382d956730bb07021c7dd1cc17229fce27b784d66fc | 2026-07-19 |
| epcis-json-schema.json | document/event validation — the projection-invariant schema | 0f46ff694efffd8d8ce840a33dfde84228add11b516b8b258f3200740ae210af | 2026-07-19 |
| epcis-context.jsonld | JSON-LD expansion checks | 5056c65f991425b1d3a35e35edf4f7d0c7ff56cf688c2912b930f93494713737 | 2026-07-19 |
| query-schema.json | SimpleEventQuery validation | 4b5583c9a0a715324594617f3cf6744f4f930568484f7df8fb7aa81819355341 | 2026-07-19 |
| epcis-shacl.ttl | semantic-graph validation (secondary) | 7db2547a7a55e7d6e6f19c0ad472d1f0987ef19f3d04a43b195bca55c0cc7f42 | 2026-07-19 |
Source of the standard: GS1 (ref.gs1.org). GS1 has not reviewed, certified or endorsed this project.
Errors in the standard's own words.
A capture that does not validate is refused as RFC 7807 application/problem+json, carrying the standard's own exception types — not a vendor error string. The 400 is the lesson: it tells you which clause of the standard you are arguing with.
HTTP/1.1 400 Bad Request
content-type: application/problem+json
{
"type": "epcisException:ValidationException",
"title": "EPCIS document failed schema validation",
"status": 400,
"detail": "/epcisBody/eventList/0: required property 'action' missing"
}The advisory suite, and what it will never sign.
The automated suite runs the GS1 test-case requirements against an EPCIS implementation and produces a run record plus a rejudgeable evidence bundle — transcript-complete, offline-recomputable, so an auditor can re-run the judgement without trusting you or us. Suite version 0.4.0, verdict logic 0.3.2, 18 checks, pinned to the GS1 EPCIS repository at commit 2b888befbc071e1c2d388e027b30149b3f51dcef.
The inventory is honest by rule: the GS1 repository publishes exactly 2 test-case-requirement documents (TCR-53, TCR-54); the Mandatory Requirements Matrix references TCR-43, which has no published document. The counts say so rather than inventing a number.
Every CLI run is marked advisory, and the CLI never signs. A signed conformance run — Ed25519 over canonical run bytes, from a hosted registrar with a named human Registrar — reaches published only when a Registrar is named: the registry's own lifecycle makes the honest posture structural. And the suite is self-applied — this gateway is graded by its own published checks; coverage.json is committed at the repository root, and the counts this page renders are read from that committed file at build time.
Point the validator at it. The proof is the exit code, not the adjective.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.