Achieving end to end visibility with EPCIS 2.0 and the CBV

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.

Whatever the setting, the mechanics underneath this topic are the same four moves: an event is captured at a door, validated against GS1's official EPCIS 2.0 schema, identified by the CBV 2.0 §8.9 hash of its own content, and appended to a store nothing can rewrite. The variations between industries and use cases are vocabulary — the CBV's business steps and dispositions — not architecture.

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.

Identity is the standard's own. The gateway computes the standardized EPCIS event hash from CBV 2.0 §8.9, with GS1 Digital Link normalization, checked against pinned reference vectors, so the same event captured twice is the same event and a changed event is a different one.

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