EPCIS 2.0 and the CBV for end to end supply chain security

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.

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.

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.

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.