Leveraging EPCIS and CBV to Improve Food Safety

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.

The concrete gain is evidentiary, not cosmetic. Events validated at capture cannot drift from the standard; the CBV §8.9 hash makes a duplicate the same event and an edit a different one; and an append-only store means the answer to a later dispute, recall or audit is a chain of records that nobody — including the operator — could rewrite. The cost that disappears is the reconciliation meeting.

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 15 August 2026.

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