The back door of a store is where your traceability record is thinnest, and direct store delivery is the reason. A DSD load — bread, dairy, produce, prepared items delivered straight to the store by the supplier's own driver, bypassing your distribution center — arrives at the receiving door, gets signed for by whoever is on the dock at 6:14am, and disappears into a process that, at most grocers, keeps no event at all. The pallet becomes inventory. The person who received it becomes a scribble on a paper manifest or nothing. And the first time anyone asks "where did this specific lot go," you find out that the answer lives in a driver's memory and a stack of delivery tickets in a back-office drawer.

Lead with why this pays for itself before we get anywhere near a compliance date: DSD receiving is already your leakiest inventory boundary and your softest shrink control. A record with a witness at the back door tightens receiving accuracy, kills the "we never got that case" disputes with DSD vendors, and shortens every investigation you run — theft, spoilage, a vendor credit, a customer complaint — not just a recall. The recall-readiness is the floor underneath an operating return you would want even if FSMA did not exist.

What FSMA 204 actually asks for at receiving

Under the FDA's FSMA 204 traceability rule, receiving a food on the Food Traceability List is a Critical Tracking Event, and for it you have to keep a defined set of Key Data Elements — including the traceability lot code, the product identifier and description, the quantity and unit, the location that shipped it, the location that received it, and the date of receipt. The obligation is record-keeping: hold the data, link it lot-to-lot, and be able to produce it in a sortable electronic form when FDA asks.

DSD is not exempt from any of that. It is simply the channel where the record is hardest to keep, because the event happens at the store's back door — the part of your operation least wired for data capture — rather than at a DC with a scanning line and a WMS. Everything FSMA 204 asks for at receiving, it asks for at the DSD dock too. The gap is not legal. It is operational.

Why the record goes silent at the back door — the structural reason

There is a deeper reason DSD keeps no usable record, and it is not laziness on the dock. It is that the event standard the whole industry is converging on has no field for the person who received the goods.

The moment you try to record a DSD receipt properly, you hit it. A supplier's dock scan and your store's receiving scan can land on the same item — the GS1 Digital Link URI in the 2D code normalizes to the same GTIN key an EPCIS event uses, so no mapping table is needed to know it is one pallet. But nothing joins those two scans with a witness. The EPCIS event model describes an event in terms of what, when, where, why, and how — and the party fields it provides are organization-grain: a source company, a destination company. The model can say your company received a pallet from their company. It cannot say this associate received this pallet at this dock at 6:14am, because there is no performer field to put a person in. The store associate who signs for the DSD delivery is the least-recorded actor in your entire chain — and the standard as written has nowhere to record them.

That is why a DSD traceback takes three days and four phone calls even at grocers who "have EPCIS." The lane knows the GTIN. The dock has a signature on paper. Nothing electronic joins them with a name attached. It is a two-ledger store, and DSD is the seam it splits along.

What a record with a witness at the dock looks like

Filling that gap is not aspirational hand-waving — it is a specific, checkable design: the capture spine behind it passes 683/683 conformance tests, its stateless doors are live at epcis.dev, and the hosted receiving product is a named entry in the open P0 ledger. The shape:

  • Every captured receiving event validates against GS1's official EPCIS 2.0 JSON schema, so the record stays conformant and portable — an auditor, a supplier, or a banner you acquire can read it without a translation layer.
  • The performer travels in a namespaced extension: who observed the pallet (the associate or the agent), stamped by the gateway alongside which account captured it and an attestation grade. Caller-supplied values in the trusted fields are stripped — the receiver cannot forge who they were.
  • Storage is append-only. No service identity holds an UPDATE or DELETE grant, so a receiving record cannot be quietly rewritten after the fact.
  • Who observed the pallet and which org they acted for are derived from grant chains at read time — so a banner acquisition or a switch of DSD logistics provider does not orphan the history.

The point is not the feature list. The point is that at the DSD dock — the one place your record goes silent — the receipt finally carries a name, and the trace stops being a phone call.

The move

DSD receiving is where the record is thinnest, where the operating return shows up first, and where FSMA 204 points. Treat the FDA date as a de-risking floor, never the urgency, and fix the back door because it tightens receiving and shortens every investigation you run. The two-clock read for the whole store — lane and dock together — is the parent: GS1 Sunrise 2027 and FSMA 204 for grocery.

If your DSD problem rhymes with a multi-unit restaurant's — the same thin receiving link, the same associate signing for a load — the QSR version of this exact seam is worth a look: RFID food traceability for restaurant chains.

Custody evidence at DSD receiving is a named entry in the open P0 ledger. The one thing to leave is an address — capture workspaces are provisioned from the seat list, in order:

→ Put me on the seat list — pick Retailer or point of sale, the segment that receives the load at the back door.

<!-- slug: