One thesis: a single 2D symbol on a case answers three different questions at three different layers — which thing, what happened, against which paperwork — and answering all three requires owning all three layers, which no vendor we can find does.
This is written for the seat that has an RFID or 2D rollout already funded and in flight and an unanswered question underneath it: where does the data live? You are measured on receiving labour and inventory accuracy, not on standards trivia. But the reason the rollout's data question stays unanswered is a standards fact, and it takes one worked scan to see it.
The scan
A serialized case arrives at your DC. The QR on it carries a GS1 element string; barcoding resolve normalizes it to canonical identity:
(01)09506000134352(17)261231(10)ABC123(21)1234
scheme gs1.element-string
gtin 09506000134352 check: mod10 pass
ai.10 ABC123 lot
ai.17 2026-12-31 expiry
ai.21 1234 serial
identity urn:epc:id:sgtin:9506000.013435.1234
That is layer one: which thing — an instance identity, not a class identity, because the serial travels with the GTIN. Layer one is pure computation; it runs locally, without an account, on every scheme in the registry.
Layer two: what happened — and who did it
The receiving scan, written down as a fact, is an EPCIS 2.0 ObjectEvent, and the family emits it properly: validated against epcis.dev's pinned official GS1 schema before it leaves the function. EPCIS gives the event five dimensions — what, when, where, why, how — and no performer. The standard's party grain is the company. A case arrived at a DC is answerable; who received it is not — there is no field to leave blank.
The family closes that conformantly, via the namespaced extension path the standard itself provides: the performer rides as who — the attested observer, a human, an agent, or an embodied agent, named in id.org.ai terms — while capturedBy carries the warrantor account whose key posted the event. Those are different grains answering different questions — who saw it versus who vouches for the record — and they never collapse into each other. The event still validates against GS1's own schema: conformant to the standard, explicit about everything beyond it.
Layer three: against which paperwork
A dock scan fulfills something. EPCIS 2.0 sanctions the join in its core fields, not in a reporting database afterward: bizTransactionList carries typed references, and CBV 2.0 §7.3 defines the types — po for the purchase order and desadv for the despatch advice, which the CBV itself glosses as "Also called an 'Advanced Shipment Notice'." The event that records the case's arrival carries pointers to the PO it fulfills and the ASN that announced it:
"bizTransactionList": [
{ "type": "po", "bizTransaction": "urn:epcglobal:cbv:bt:9506000000018:PO-4711" },
{ "type": "desadv", "bizTransaction": "urn:epcglobal:cbv:bt:4098765000006:S2607311420" }
]
The PO and ASN live on transactions.dev's side of the family; source and destination parties join on GLNs per CBV §7.4; aggregation joins on the SSCC per §8.5. Every one of these joins is a spec-sanctioned core field. None of them is glue we invented.
Why three layers means three properties
Run the gap analysis we ran, and state it as what it is — our search result, checkable against the public record. The vendors adjacent to this problem are one of four things:
- Walled — the syndication networks (product content behind membership and per-brand consent regimes) and the visibility networks whose record is authoritative only because you joined them.
- Dead — the category's most instructive precedent: a major scanner vendor's single-API barcode-enrichment product, retired entirely in December 2023, its Track & Trace sibling gone in the same purge.
- Shallow — the official verification rail stops at a handful of attributes, and stops entirely at the event layer.
- Unlicensed — the 500M-product aggregators, serving attributes with no per-attribute source, no license class, and redistribution-hostile terms of their own.
Nobody in that field connects identifier master data to EPCIS event streams or to PO/ASN-grain business transactions. The intersection — identity resolution, events with a performer, transactions joined by core fields — is unoccupied. That is not a feature comparison; it is the reason your rollout's data question has no incumbent answer.
What is live, and what is gated — plainly
The identity layer runs today, locally, free: resolve, verify, and generate are pure verbs — no account, no network, every GTIN on earth plus VIN, ISBN, UDI, NDC, SSCC and tracking formats through one door. The event construction validates against epcis.dev's pinned schema, and the scheme registry pages document every join rule.
The full chain — your receiving scans becoming attested events joined to your POs and ASNs, hosted, with sharing grants across your franchise boundary — is the gated capability, and we gate it honestly rather than demo-ware it. If that chain is the answer to your rollout's open question, tell us who you are and answer a few questions about your fleet, your DCs, and your supplier set. The receiving scan your handhelds already produce carries enough structure to be all three layers. The part worth deciding this quarter — while the rollout is still in flight — is where the record lives.
Keys open the network half of the verb set. Get an API key — say what arrives at your door, and the provisioning order follows the list.
We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read.