One thesis: the instant your system writes a 2D scan down as an event, you inherit a gap in the governing standard itself — EPCIS 2.0 records what, when, where, why and how, and has no dimension for who performed the observation. This is not a data-quality problem you can fix with discipline. It is a structural absence, and the distinction decides your architecture.
From payload to event, mechanically
A serialized 2D payload is an event waiting for a timestamp. Parse one:
$ barcoding resolve '(01)00036000291452(10)L23085(21)00417' --json
{ "scheme": "gs1.element-string", "canonical": "00036000291452",
"check": "mod10 pass",
"ai": { "10": "L23085", "21": "00417" },
"identity": "urn:epc:id:sgtin:0036000.029145.00417" }GTIN plus serial is an SGTIN — an instance, so it goes in an ObjectEvent's epcList and can be traced. GTIN plus lot is an LGTIN — a class quantity, so it goes in quantityList and can only be counted. The AI map decides the field; the field decides which questions your event history can ever answer. Add eventTime, bizStep, readPoint, and you have an EPCIS 2.0 ObjectEvent — which the family treats as non-negotiable: the join validates every emitted event against the pinned official GS1 schema on epcis.dev before it leaves the function. Its /validate door answers in production; point it at anything on this page.
So far, mechanical. Now look at what the event can say.
The five dimensions, section-numbered
The citations below are the proof artifact of this post. They are all public, and checking them takes ten minutes.
- EPCIS 2.0 §7.2.2 defines the event dimensions: what (epcList/quantityList), when (eventTime), where (readPoint/bizLocation), why (bizStep/disposition/bizTransactionList), how (sensorElementList). Five dimensions. Read the list twice: no performer is among them.
- EPCIS 2.0 §7.3.6.4 and CBV 2.0 §7.4.3 / §8.7.1 define the party fields the standard does have — source/destination parties and PGLNs. Every one of them is organisation-grain: a legal entity, a location. A company.
- EPCIS 2.0 §6.3 / §9.1 / §10.1.3 define the extension mechanism: namespaced user extensions are conformant, carried in the event, ignored losslessly by repositories that do not know them.
Put the three together and the standard's position is exact: a Company doing a Process is fully answered; a worker doing a task — which human, which agent, which device performed this observation, at the moment of the scan — has no field. Not an optional field. No field.
Why "structural" is the stronger claim
If the Who were a data-quality problem, the fix would be process: mandate badge scans, audit the capture app, tighten the SOP. But there is nothing to tighten — an EPCIS event with a diligently operated capture process still cannot say who scanned, because there is nowhere to put it. The absence survives perfect operations. That is what structural means, and it is a stronger, more defensible statement than any complaint about sloppy data: you can verify it by reading the schema, not by auditing anyone's warehouse.
The consequence lands on exactly your desk. Every downstream question that matters in an incident — who received this pallet, which associate broke the case, which agent reconciled the count — terminates at an organisation-grain record that answers "the company did." When the audit question is about a person or an agent, the record's best answer is a shrug with a GLN on it.
And the volume of the problem is about to change on a published clock: as 2D marks spread through the Sunrise transition, every scanner in your estate becomes a potential event source emitting serialized payloads. More scans, richer payloads, same missing dimension — multiplied.
The conformant path forward
The extension mechanism is the honest answer, and it is the one the standard itself provides. A namespaced extension field carries the performer; the event still validates against GS1's pinned official schema; a repository that has never heard of the extension ignores it losslessly. Conformant to the standard; explicit about everything beyond it — that is the family's whole posture in one sentence, and §6.3/§9.1/§10.1.3 are why it is a posture and not a fork.
What belongs in that extension is a harder question than it looks — the observer who performed the scan and the account that warrants the record are different grains, an agent may observe under an account it does not own, and collapsing the two destroys exactly the evidence a custody record exists to carry. The observer's identity grain — Agent. Human. Thing. — is id.org.ai's territory in this family; the two-grain design gets its own post, worked at a receiving dock. Capturing events with the Who attached, durably and at production grain, is what the access flow exists to scope — say what scans at your sites, and the provisioning order follows the list.
Close with the check, because every claim above is checkable without us: EPCIS 2.0 §7.2.2 · CBV 2.0 §8.7.1 — ten minutes, the specs are public, don't take our word for it. If your platform is about to write scans down as events, read those two sections before you freeze the schema. The dimension you don't reserve space for now is the one the audit will ask about later.
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.