Overcoming challenges in implementing EPCIS for supply chain management

Whatever brought you to this page, the standard underneath it is EPCIS 2.0 — GS1's model for supply-chain event data — and the discipline underneath the standard is a door: epcis.dev validates each event against GS1's own schema, stamps the capturing account (capturedBy, the warrantor, kept distinct from who, the attested observer), hashes it by CBV 2.0, and appends. Everything below assumes that door.

The implementation order that works: validate first — every event against the official GS1 schema, failures refused in the standard's own exception types — then bring the archive along, EPCIS 1.1/1.2 XML through translation with a per-job fidelity report, then make the store append-only so custody is structural rather than promised. Each step is checkable on its own before the next begins, and this gateway implements all three.

Reads are minimally scoped. You see your own scope; what is outside it is absent, not greyed out and not redacted, so there is no shape left behind to argue about. Recording an event is $0 by policy — intent, until published terms bind it — because a stream that charges per event is one you stop feeding the month the bill grows with volume.

Custody is structural, not promised. No service identity holds an UPDATE or DELETE grant; the write path has exactly one writer and it can only append. You can add an event; you cannot un-write one, which is what makes a later trace evidentiary rather than merely stored.

Provenance: an aged epcis.dev page, kept at its original URL and refreshed into the current design on 8 September 2026.