Two grains of performer: the attested observer and the warrantor account.

31 July 2026 · the launch journal

Here is the data-model question that belongs on your review checklist, stated once and hard:

who is the attested observer — the identity, human, agent, or embodied agent, that actually performed the observation. capturedBy is the warrantor account — the principal whose key opened the capture door and who stands behind the record's admission. They are different fields with different meanings, and a system that collapses them destroys exactly the evidence a dispute needs.

EPCIS 2.0 core has neither — its party fields stop at organisation grain (PGLN, CBV §7.4.3/§8.7.1) — so this gateway carries both as a two-grain envelope over the conformant record, in namespaced extension fields the official schema accepts (EPCIS §6.3/§9.1/§10.1.3).

The delegation case that forces the split.

The forcing case is already routine on this origin: a coding-class agent, deputized inside an engineer's session, captures events under the engineer's key. The agent is the observer. The engineer's account is the warrantor. One identity saw it; a different identity stands behind it.

The committed corpus fixture golden-corpus/valid-envelope/object-event-attested-observer.json is the minimal honest record of such a moment — a dock-scanner agent observing an inbound receipt:

{
  "type": "ObjectEvent",
  "eventTime": "2026-07-19T11:45:00.000Z",
  "eventTimeZoneOffset": "+02:00",
  "epcList": ["urn:epc:id:sgtin:0614141.107346.2021"],
  "action": "OBSERVE",
  "bizStep": "receiving",
  "disposition": "in_progress",
  "readPoint": { "id": "urn:epc:id:sgln:0614141.00999.0" },
  "spine:who": "https://id.org.ai/agents/dock-scanner-7",
  "spine:activity": "https://event-spine.internal/activities/inbound-receiving/run/42"
}

spine:who is supplied by the capturing side and attested — an id.org.ai identity (Agent. Human. Thing.), not a free-text name. spine:capturedBy is not in the payload at all, and that is the design: it is a trust-boundary field, stamped by the gateway from the authenticated key, stripped from any payload that tries to assert it. Here is a real read-back through the query door, stamps visible:

{
  "type": "ObjectEvent",
  "eventID": "urn:uuid:6f9b62a2-5c1e-4c39-9e2b-1a2b3c4d5e6f",
  "bizStep": "shipping",
  "recordTime": "2026-07-31T12:46:32.566Z",
  "spine:capturedBy": "urn:epcis.dev:cli:local",
  "spine:attestationGrade": "anonymous"
}

The sender cannot forge capturedBy, because the sender never writes it. The gateway cannot invent who, because the gateway never observed anything. Each field has exactly one honest author.

What each field answers in an audit.

Run the dispute forward. A pallet of temperature-sensitive product is marked received in good order; three weeks later the customer claims it never crossed the dock. The record is subpoenaed, or merely escalated. Two questions arrive, always:

• "Who saw it?" — who: dock-scanner-7, an embodied agent, at that read point, inside activity run 42. That identity has an attestation chain you can follow at read time.
• "Who stands behind this record being here?" — capturedBy: the account whose key admitted the event, with its attestationGrade stating how strongly the door verified the observer claim.

Now collapse the two into one field — call it capturedBy, as most homegrown schemas do — and replay the case. The record says the integration service account received the pallet. The account holder was not on the dock; the account is a Kubernetes secret. You can no longer distinguish "our agent observed this under our service key" from "someone with our key asserted this." The observer evidence and the warrant evidence have been averaged into a single value that proves neither. That is not a hypothetical failure mode; it is the default failure mode of every created_by column ever shipped.

And the company grain is neither of them.

Your next question is the right one: where does which legal entity live? Answer: in the standard's own organisation-grain fields where the business context asserts it (sourceList/destinationList, CBV party types) — and, for the performer chain, derived at read time from the grant chain, never stamped onto the event. who resolves to an identity; the identity's employment, deputization, and key-issuance edges are facts of the identity layer with their own validity intervals. Stamp "employer" onto an event and you have frozen an org-chart edge into an immutable record — wrong the day the contractor converts, unfixable in an append-only store. Derive it, and the same event answers correctly forever.

For your questionnaire, the properties that fall out, each checkable against the fixture and the pinned schema:

1. Non-forgeable warrant — capturedBy/recordTime/attestationGrade are server-stamped; payload values are stripped at the door.
2. Attested observation — who is an attested identity reference, not prose; its grade is recorded, not implied.
3. Conformant carriage — the envelope projects down losslessly to standard EPCIS 2.0; npx epcis.dev validate on the fixture exits 0 against the pinned official 2.0.1 schema.
4. No stamped org grain — party/org facts are derived from grant chains at read time, so the append-only record never petrifies an org chart.

The performer model in full — including why the core standard has no such field to begin with — is the Who article. The attested-Who capture path runs on the hosted spine behind a capture key: keys are provisioned from the list at /get-a-key/, in order — the two questions the flow asks exist so your key lands configured for the grain your review is actually about.

Two fields. Two authors. Two answers in the dispute. Keep them apart.