Using EPCIS 2.0 and the CBV with big data analytics

Start from the record, not the buzzword. An EPCIS 2.0 event is a validated, hashed, appended fact, and epcis.dev is a capture gateway that enforces exactly that: GS1's own schema at the door, the capturing account stamped — capturedBy, the warrantor, kept distinct from who, the attested observer — the CBV 2.0 hash as the event's identity, and no way to un-write. The topic above is read against that record.

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.

Ten years of vendor XML has a path forward: EPCIS 1.1, 1.2 and 2.0 XML in, EPCIS 2.0 JSON-LD out, with a round-trip fidelity report per job so the translation is something you review rather than something you trust. That translator answers at POST /translate on this origin.

Two attributions travel with every event, and the door owns a different half of each. capturedBy is the warrantor — the account whose key opened the door — stamped by the gateway together with recordTime and the attestation grade, with caller-supplied values in those stamped fields stripped. who is the attested observer, asserted by the caller and graded by the door: it reaches only the grade claimed until identity attestation lands. One is stamped, the other is graded; they never merge.

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