Managing recalls with EPCIS 2.0 and the CBV

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.

Traceability holds only when the record would hold up out of context: validated at capture against GS1's official schema, identified by the standard's own hash, appended and never edited, with the capturing account stamped by the gateway rather than asserted by the sender. That is what turns a trace from a report someone compiled into evidence someone else can check.

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.

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.

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