EPCIS 2.0 has five dimensions and no performer. Count them.

31 July 2026 · the launch journal

You were handed the build mandate, so you get the claim in checkable form: EPCIS 2.0 §7.2.2 defines an event as answering five dimensions — what, when, where, why, how — and no performer is among them. Not deprecated, not optional, not hidden in an appendix: there is no field in the core event model for the worker, the agent, or the device operator who performed the observation. The absence of a Who is structural — there is no performer field to leave blank — and you can verify that against the public documents in about ten minutes, without taking anyone's word for it, ours included.

The five, as the spec defines them.

Read §7.2.2 of the EPCIS 2.0 standard (the PDF is a free download from GS1; the normative JSON schema and OpenAPI are published at ref.gs1.org and vendored on this origin, sha256-pinned on the conformance page). Each dimension answers one question about a single observed moment:

dimension	question	core fields
what	which objects were seen	epcList, quantityList, parentID, input/output lists
when	at what moment	eventTime, eventTimeZoneOffset
where	at which point, in which place	readPoint, bizLocation
why	in which business context	bizStep, disposition, bizTransactionList, sourceList/destinationList
how	under what conditions	sensorElementList

Five questions, fully specified, with a CBV vocabulary behind each. The sixth question — who performed this — has no row because it has no fields.

"But sourceList has parties in it."

It does, and this is where the ten-minute check earns its time. The party fields the standard carries are organisation-grain. EPCIS §7.3.6.4 defines source and destination elements; CBV 2.0 §7.4.3 enumerates the party types (owning_party, possessing_party, location); and §8.7.1 specifies the identifier grain: a PGLN — a Party Global Location Number. A PGLN names a legal entity. It answers which company owned the goods, which company possessed them, which site they moved through.

So the standard's Who is a company doing a process. Acme Corp shipped the pallet is fully representable. Dock worker 7 — or the coding-class agent running in your integration session — scanned the pallet at 11:45 is not. The Who stops at the GLN. A Worker doing a Task is a different grain from a Company doing a Process, and only one of those grains has a field.

That distinction is not pedantry. It is the difference between an event record that supports a dispute ("who actually saw this?") and one that supports a org chart lookup ("which company's key sent this?"). When agents start capturing events — and on this origin they already do, over the MCP door — the performer question arrives on every single event, and the core model has nowhere to put the answer.

The path the spec itself leaves open.

The standard is not embarrassed by this; it provides for it. EPCIS §6.3, §9.1 and §10.1.3 define the user-extension mechanism: fields under a declared JSON-LD namespace, riding inside an otherwise standard event, invisible to consumers that don't speak the namespace and fully valid against the official schema. That is the sanctioned way to carry a grain the core model does not.

It is exactly the mechanism this gateway uses: a two-grain envelope over the conformant record, in which who is the attested observer and capturedBy is the warrantor account — two fields, two meanings, never collapsed — carried as namespaced extension fields, projecting down losslessly to standard EPCIS 2.0. The corpus fixture object-event-attested-observer.json shows the shape, and the pinned official schema accepts it:

$ npx epcis.dev validate object-event-attested-observer.json
valid	schema=epcis-json-schema.json	version=2.0.1

The full performer model is written up in the Who article; the identity layer the observer values resolve through is id.org.ai — Agent. Human. Thing. The executive-register version of the same gap, for the person above you who reads briefs instead of schemas, is at visibility.cloud.

Go check it without us.

The whole point of a structural claim is that you don't need the claimant. The checklist, in the order that takes the least time:

§7.2.2 — count the dimensions. Five. Note what each answers.
§7.3.6.4 — read the source/destination model. Note the grain.
CBV §7.4.3 and §8.7.1 — the exactly-three party types and the PGLN identifier grain. This is where "the Who is a company" becomes literal.
§6.3 / §9.1 / §10.1.3 — the user-extension path. Note that a namespaced performer field is conformant by the standard's own design.

Ten minutes, public documents, zero trust required. If your read of those sections disagrees with ours, that is a conversation worth having — and you'll be the rare reviewer who arrives with section numbers.

Then run the claim instead of reading it: npx epcis.dev validate on any event you have (the validator is pinned to the official 2.0.1 schema — digests on /conformance/), or POST the document to /validate on this origin, no key, no account. Run it yourself is the five-minute version. When you want the attested-observer grain flowing through your own capture path, keys for the hosted capture spine are provisioned from the list at /get-a-key/, in order.

Five dimensions. No performer. Now you've counted them yourself.