Every Director of Food Safety at a multi-unit restaurant company has run the exercise: pick a lot, start the clock, prove you can trace it from supplier to store inside 24 hours. And most have lived the version where the clock ran four days. The instinct is to blame execution — someone was on vacation, the DC's report format changed, the franchisee's ops lead didn't answer until Monday. The truth is structural, and it is checkable in the standard's own text.
What follows is a worked timeline. It is illustrative — a fictional-but-realistic composite of how these exercises actually run — but every failure point in it is a failure the record's own structure guarantees.
The exercise as run
The target: one lot of diced chicken, produced at a co-manufacturer's plant, shipped through your DC network to company and franchise stores in two regions.
Hour 0 Exercise begins. Lot number pulled from the co-man's COA email. Hour 1 ERP shows a PO and an invoice against the supplier. No lot on either. Hour 3 Co-man's customer-service contact reached. They confirm the lot shipped in three ASNs. Which cases went to which DC: "we'll pull it." Hour 9 Co-man responds: case ranges per DC, as a PDF of a spreadsheet. Hour 10 DC 1 confirms receipt in the WMS. Received by: "DOCK-04". Hour 11 DC 2 confirms receipt. Received by: blank. Day 2 Store-level distribution begins. Company stores answer from the back-office system by end of day. Day 2-4 Franchise stores. The data is contractually the franchisee's. Twenty-two phone calls, one ops-lead vacation, one system that purges receiving records at 30 days. Day 4 Trace closed. Elapsed: 76 hours. Confidence in store-level disposition: "high" for company stores, "moderate" for franchise.
Now look at where the time went. Almost none of it was spent moving data. Nearly all of it was spent finding a person who could vouch for a handoff — because the record itself could not.
The structural reason: five dimensions, no performer
EPCIS 2.0 — the GS1 standard for supply-chain event data, and the right standard for this job — defines an event along five dimensions. Section 7.2.2 of the specification names them: what was observed, when, where, why (the business step), and how (the sensor and condition context). Read the list again: no performer is among them. The standard's party fields identify organizations — a company doing a process — never the person or agent who performed the step at the moment of the scan.
That is why hour 11 looks the way it does. The receiving event at DC 2 is a perfectly formed record: right GTIN, right timestamp, right GLN. It says a case arrived at a location. It cannot say who received it, because there is no field in which to say it. "Received by: blank" is the standard operating exactly as designed — and this is a structural absence, not a data-quality problem, which is why no amount of training or dashboard-buying fills it in.
At an organizational boundary, that absence compounds. Inside your own walls you can walk to the dock and ask. Across the franchise line and the co-man line, the record is the only thing that crosses — and a record with no performer means every hop resolves to a phone call to someone who might remember. Twenty-two calls is not an execution failure. It is the record's grain, experienced as elapsed time. The franchise-boundary version of this problem has its own worked read: FSMA 204 mock recalls across the franchise boundary.
The same exercise over a performer-complete record
visibility.cloud records events with two grains the standard's five dimensions do not carry, kept strictly distinct: who — the attested observer, the human, agent, or embodied agent that performed the step — and capturedBy — the warrantor account that stands behind the capture. An agent can observe under an account it does not own; collapsing the two fields is how records lose either attribution or accountability, so they never collapse. Party and organization grain are derived at read time from grant chains, never stamped onto the event — which is what keeps the history true across a reorg or a franchise transfer.
Over that record, the exercise reads differently. The trace view renders the lot's history as a hop-by-hop timeline: every receiving event with its location, its time, its who, and its warrantor, across your DCs and every store that granted you the view. The four-day version's phone calls existed to reconstruct exactly the column that is now simply present. What the timeline still cannot do is compel a franchisee's grant — data rights remain a contractual question — but it converts "call someone who might remember" into "read the row, or see precisely which counterparty's grant is missing." (Who held it is the dimension this whole platform exists to answer; the standard's own gap, with section numbers you can check without us, is laid out at Who held it.)
The one KPI a board understands
Elapsed time is the number to publish internally. Not scan rates, not tag counts, not "traceability coverage" — the hours from lot named to disposition known, with confidence. It is the number a mock recall produces naturally, the number FSMA 204's traceback logic implicitly tests, and the number that either shrinks or doesn't when you change the record. The four-day exercise above is a 76 on that scale. The structural ceiling on improving it is not effort; it is whether your record carries a performer at every handoff that matters.
The full restaurant-chain read — where RFID fits, what the public record supports, and what receiving capture should look like — is the pillar: RFID and food traceability for restaurants. The honest read on the compliance clock behind all of it is FSMA 204's real date.
Run your own number
If your last exercise's elapsed time is a number you would rather not say out loud, that is the felt trigger this platform is built for. The way in is the interview: email first, under a one-message promise, then a short branching sequence about how your chain actually runs — DCs, franchise mix, supplier set — ending in a written read for your situation. The final step locks; it is written once per address.
→ Start the interview — it is questions, not a demo.