The Future of Inventory Management with EPCIS and 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.

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 register on 31 July 2026.

Proof, not adjectives. The gateway's conformance tests pass against GS1's normative artefacts, and the calculators answer on this origin — POST /translate, /validate, /hash, no key. The dated ledger is What ships today.

What ships today →

get a capture key

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.