The Role of EDI Transactions in EPCIS and CBV

The gateway framing matters for this topic: epcis.dev accepts an event only after validating it against GS1's own schema, stamps the capturing account — capturedBy, the warrantor, kept distinct from who, the attested observer — identifies it by its CBV 2.0 hash, and appends it to a store nothing rewrites. What follows stands on those mechanics.

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.

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.

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.