A traceability record is worth exactly what it proves to someone who never joined your vendor's network. A record that is authoritative only because both parties subscribed to the same platform is a membership card, not evidence — and the day it matters most is the day it is read by someone who refused to join: a regulator, an auditor, a counterparty's counsel.
This is the one sentence we need to land in every room, so this brief performs it rather than asserting it. Below is the verification a counterparty can run on one of your events with no account, no login, and no relationship with us. Every input is public.
The network-effect trap, stated plainly
The incumbent architecture works like this: you join a network, your partners join the same network, and the network's copy of the record becomes "the truth" because everyone contracted to treat it that way. Authority by subscription. The record's evidentiary weight evaporates at the network's edge — precisely where disputes, audits, and regulatory requests live. If your last vendor evaluation never asked "can a non-member verify this record?", that is the question this brief hands you.
The walkthrough, performed
Take one receiving event — illustrative throughout, with the identifiers drawn from GS1's own documentation range:
{ "type": "ObjectEvent", "eventTime": "2026-07-30T14:02:11.000Z", "eventTimeZoneOffset": "-05:00", "epcList": ["urn:epc:id:sgtin:0614141.107346.2018"], "action": "OBSERVE", "bizStep": "receiving", "disposition": "in_progress", "readPoint": { "id": "urn:epc:id:sgln:0614141.00777.0" } }
Step 1 — validate it, against GS1's schema, not ours. The event either conforms to the official, pinned EPCIS 2.0 JSON schema or it does not, and the check runs against GS1's published artifact:
curl -X POST https://epcis.dev/validate \ -H "content-type: application/json" \ -d @event.json
The validator at epcis.dev is precompiled over the official GS1 schemas with sha256 provenance pins, so "valid" means valid against the standard's own text — a claim anyone can reproduce with the schema and any validator they trust instead of ours. No conformance attestation has ever been issued, to us or by us; the claim is exactly the reproducible check, nothing softer and nothing grander.
Step 2 — recompute its identity. CBV 2.0 §8.9 defines a standardized event hash: a canonical pre-hash string is assembled from the event's fields in the order the section prescribes, EPC URIs are normalized to their GS1 Digital Link form, timestamps are normalized to UTC, and the string is hashed with SHA-256. The normalization is arithmetic, so do it by hand and check us: urn:epc:id:sgtin:0614141.107346.2018 carries company prefix 0614141 and the six-digit field 107346, which is indicator 1 followed by item reference 07346; the GTIN-14 is the indicator, then the prefix, then the reference — 1 0614141 07346 — and the mod-10 check digit over those thirteen digits is 4. So the EPC normalizes to https://id.gs1.org/01/10614141073464/21/2018 — and a reader who derives a different string there will derive a different digest below, which is the whole point of printing the working:
curl -X POST https://epcis.dev/hash \ -H "content-type: application/json" \ -d @event.json ni:///sha-256;28e1e21f...?ver=CBV2.0 (illustrative)
Our implementation of §8.9 is gated against the OpenEPCIS reference vectors — someone else's answers, not our own — so the digest a counterparty computes with their tooling matches the one we publish.
Step 3 — compare. The recomputed digest either equals the event's stated identity or it does not. If any field was altered after the fact, the identity breaks; the how and the consequences are worked through in the computed-identity brief.
At no point did the verifier create an account, accept terms, or join anything. The schema is GS1's. The hash algorithm is CBV 2.0's. The reference vectors are OpenEPCIS's. Our role is to keep records that survive exactly this treatment — and to serve, for every event we hold, a public verification surface where these three steps run in one place.
Who this matters to
The regulator, who will not join your vendor's network and should not have to. The auditor, whose profession is re-derivation — the audit-day consequences are the subject of nothing separate to audit. The counterparty who refused to join — the majority of every real supply chain — whose dispute with you turns on whether your record means anything in their hands.
The two-grain envelope carries into the same discipline. Every event the capture engine writes distinguishes who — the attested observer, human, agent, or embodied agent — from capturedBy, the warrantor account that stands behind the capture; the engine is built and that separation is held by a named passing test. Both are part of the record a counterparty verifies, and neither collapses into the other; evidence that cannot say who observed and who warrants is evidence with a hole where the cross-examination goes.
The procurement question
Put it in your next RFP, one line: "Describe how a party with no commercial relationship to you or to us verifies the integrity and conformance of a single event record." Score the answers on how many steps require an account. The Sunrise 2027 brand-owner read covers the program decisions that lead here; when the event layer is the open one on your plan, get started — the interview branches for brand owners, and the program-office questions are in it.