`who` Is Not `capturedBy`: The Two Grains Every Custody Record Needs

A regulator working a traceback asks two questions about any receiving event, and they are not the same question. Who did it? And who stands behind the record? Most systems that claim to answer "who" store one field — a user ID, a badge number, a login — and quietly answer both questions with it. This post is about why that single field fails, walked through three receiving events that happen at real docks every day.

The vocabulary first, because the vocabulary is the product. On this record, who is the attested observer — the human, agent, or embodied agent that performed the observation. capturedBy is the warrantor account — the party whose key wrote the record, the one that stands behind the capture. They are distinct fields, always, because an observer may act under an account it does not own. The standard itself has room for neither at the person-or-agent grain: EPCIS 2.0 §7.2.2 defines five event dimensions — what, when, where, why, how — and its party fields are organisation-grain (CBV 2.0 §8.7.1, PGLN). That structural fact is checked in ten minutes and worked in full in Five Dimensions, No Performer; this post is about what fills the gap correctly.

Three receiving events, three different pairs

Event one — the crew member on a handheld. A DC associate scans a case of covered produce off a supplier truck. The record reads:

Observer and warrantor are different parties even in the simplest case: a person performed the scan, and the operating company stands behind the capture. Merge the fields and you must choose which fact to keep. Keep the person and no organisation warrants the record; keep the account and the person disappears — which is precisely today's status quo, and precisely why your last mock recall's timeline has a phone call where a name should be.

Event two — an agent scanning under a supervisor's account. A software agent, working under a seat a QA supervisor provisioned, ingests the morning's receiving reads and captures the events. The record reads:

Here the two grains stop being a nicety and become the whole answer. The agent observed; the supervisor warrants. If the fields merge, either the agent appears as the supervisor — a falsified record, the kind an audit unwinds badly — or the supervisor vanishes and an unaccountable process warrants itself. Neither survives the second question a regulator asks.

Event three — the contractor under the site account. A third-party receiving crew works the dock during peak. A contractor scans; the site account captures.

The contractor's employer is not the warrantor and the warrantor is not the observer's employer. One field cannot hold that triangle. Two can — and note what is absent: no organisation is stamped on the event at all. Which company the observer belonged to that quarter, and which business unit the site rolled up into, are derived at read time from grant chains, never stamped on the event — so the record stays true when the org chart above it changes.

The collapse test

Run any single-field design through the three events and watch what each scenario loses. Event one loses either the warrantor or the person. Event two loses the difference between delegation and impersonation. Event three loses the triangle entirely — most systems record it as "the site did a receiving," which is exactly the organisation-grain sentence the standard could already say without anyone buying anything.

The identity behind each who — person, agent, or thing — resolves through id.org.ai: one grain for all three kinds of observer, which matters more each quarter as the third kind arrives on your docks; the embodied case is worked in When the Observer Is a Robot. And all of it rides conformantly: the record is a superset of EPCIS 2.0 that stays conformant — the projection validates against GS1's official pinned schema, with the two-grain envelope in the standard's own namespaced extension path.

What this buys you on the day it matters

You have run the 24-hour exercise. You know where it broke: the record crossed a boundary — the franchise line, the co-man line, the DSD door — and went silent, because a company-grain record cannot answer a worker-grain question. The written read for that whole failure mode is the RFID and food traceability brief for restaurant operators, and the specific franchise-boundary anatomy is worked in the mock-recall case study. With the two grains populated, the same traceback reads differently: every hop names its observer and its warrantor, the elapsed time collapses from days of telephony to a query, and the two questions the regulator asks get two answers that were recorded at the moment of the scan — never reconstructed afterward.

The vocabulary to require in any vendor conversation, then, is exactly two words long. Ask where the observer lives. Ask where the warrantor lives. If the answer is one field, you now know which of your three receiving events their record cannot survive.

The door here is the get-started interview: your email first, then a short interview that branches on your answers — the restaurant-and-distribution branch asks what triggered your last trace-back and how long it took, whose data a franchise unit's scan contractually is, and where your scanning reads land today. We answer in writing.