Understanding the technical requirements of EPCIS 2.0 and the 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.

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.

The part epcis.dev makes concrete is validation. Every event is machine-checked against the official GS1 EPCIS 2.0 JSON schema before it is accepted, and a capture that does not validate is refused as application/problem+json carrying the standard's own exception types, not a vendor error string.

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