# 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](/conformance/)). 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 **organization-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](/mcp/) — 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](/journal/who-is-not-capturedby/) — 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](/epcis-who-performer-worker-agent/); the identity layer the observer values resolve through is [id.org.ai](https://id.org.ai/) — Agent. Human. Thing. The executive-side version of the same gap, for the person above you who reads briefs instead of schemas, is at [visibility.cloud](https://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:

1. **§7.2.2** — count the dimensions. Five. Note what each answers.
2. **§7.3.6.4** — read the source/destination model. Note the grain.
3. **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.
4. **§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/](/conformance/)), or POST the document to `/validate` on this origin, no key, no account. [Run it yourself](/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 requested from the list at [/get-a-key/](/get-a-key/).

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

---

**Proof, not adjectives.** This build could not verify the gateway's test suite green, so no sentence on this page claims a passing run — the last verified run is recorded in the repository's own CI, not here. Live on this origin, no key: POST /translate, /validate, /hash. No conformance attestation has ever been issued. The dated ledger is /what-ships-today/.