Walk one direct store delivery with me, because the Director of Food Safety who owns fresh already knows this route by heart: the bread truck, the soda truck, the local dairy — and for the covered categories, the seafood distributor and the produce jobber — arrive at the back door, not the DC. A driver wheels cases in. A store associate meets them, counts, signs, and puts the load away. The whole transaction takes eleven minutes, and it happens tens of thousands of times a week across your banner.

Now ask the traceback question about any one of those eleven-minute windows: who received it?

What each system captures — and the person none of them record

At that back door, on a good day, three systems are watching:

  • The DSD system posts the delivery against the vendor's invoice: items, quantities, dollars. It exists to settle money, and it is good at that.
  • The inventory system increments on-hand for the store. It knows the case count changed; it has no idea who changed it.
  • The vendor's own handheld records proof-of-delivery — often with a signature squiggle that is legally a signature and informationally nothing.

Each captures the transaction at the grain it was built for. None captures the one fact a foodborne-illness traceback, a temperature-abuse investigation, or an FDA records request eventually turns on: which person, standing at which door, at which minute, accepted custody of this covered food. Under FSMA 204 that back-door moment is a Critical Tracking Event with named Key Data Elements — the receiving side of the obligation is walked through in the fresh-department scoping guide and the DSD record at the back door — and the KDE set at least forces lot, location, and date into the record. The person still is not there.

This is a missing field, not sloppy data entry

Here is the part worth ten minutes of your own time, because it changes what kind of fix you fund. The right standard for supply-chain event data is GS1's EPCIS 2.0, and its specification defines an event along five dimensions — section 7.2.2: what, when, where, why, and how. Read the list: no performer is among them. The standard's party vocabulary — CBV 2.0, section 8.7.1 — identifies parties by PGLN, at organisation grain: a company can be named in an event; a person cannot. The Who the standard carries is a company doing a process, one grain too high for the question the investigator is asking.

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.

The consequence: "the associate isn't in the record" is not a training problem, a compliance problem, or a data-quality problem. There is no field to fill in better. Any vendor telling you their EPCIS-based system records who signed at the back door is either extending the standard — ask them exactly how, and how it survives validation — or describing the company field and hoping you don't ask. The full statement of this gap, with every section number, is this site's standing read: Who held it.

What an attested observer adds to a traceback

visibility.cloud records the back-door moment with the two grains the standard leaves out, kept strictly distinct. who is the attested observer — the associate who actually met the truck, or the agent or device that performed the receipt. capturedBy is the warrantor account — the party standing behind the capture. The distinction matters precisely at DSD: the observer may be a part-time associate, the warrant is the store's; merge the two fields and you lose either the attribution or the accountability. Party and organization grain are derived at read time from grant chains, never stamped on the event — so the record survives a banner reorganization with its history intact.

Over that record, the FDA request that today triggers a store-by-store archaeology — produce your receiving records for lot X of smoked finfish, all stores, DSD included — is a query: every receiving event for the lot, each with its location, date, quantity, lot code, and its who, rendered as a custody-evidence view you can hand across the table. The projection of every event validates as conformant EPCIS 2.0 against the pinned official schema — no conformance attestation has ever been issued, and none is claimed — so the evidence holds up for a counterparty who never joined anything of ours.

Same GTIN at the lane and the dock — nothing joins them with a witness today

One more reason DSD is the place to fix first. Grocery is the only segment sitting on both clocks at once: under GS1's Sunrise 2027 programme your lanes are being refreshed to scan and process 2D barcodes by end of December 2027, and under FSMA 204 your back doors are receiving covered foods. The same GTIN crosses both thresholds — richer-marked at the lane, obligation-laden at the dock — and in today's architecture nothing joins the two observations, and neither carries a witness. A chain that fixes the dock record while the lane refresh is already moving capital gets one event spine under both, which is the whole argument of the pillar: Sunrise 2027 and FSMA 204 for grocery.

DSD receiving is simultaneously your thinnest record, your highest-risk categories, and your least-instrumented door. That combination is why it goes first.

Where this goes next

visibility.cloud provisions capture workspaces from the seat list, in order. The way in is the interview: email first, under a one-message promise, then a short branching sequence about your operation — DSD share, covered categories, back-door process — ending in a written read for your situation. The final step locks.

→ Start the interview — it is questions, not a demo.