You have run the mock recall. You know precisely where it fell apart — and it was not the clock. The 24 hours was never the hard part. The hard part was the moment the record went silent, someone said "I'll have to call the DC," and a query became a phone tree. This article is about running the exercise properly, finding that break point on purpose, and understanding why it is a structural break — not a discipline problem you can train your way out of.

A framing note before the mechanics, because it decides everything about how you should prioritize this: FSMA 204 is the floor, not the fire. The reason to close the recall gap is operational — you do not want a lot-scope question answered in phone calls whether or not a regulator ever asks. Treat the deadline as a backstop that de-risks the work, and read the actual regulatory status below before anyone sells you urgency.

What does a 24-hour FSMA 204 mock recall actually test?

FSMA 204's recordkeeping requirement is built so that a covered operation can produce its traceability records — the Key Data Elements for each Critical Tracking Event — in an electronic, sortable form within 24 hours of an FDA request (FDA Food Traceability Rule). A proper mock recall tests three things, and most run-throughs only really test the first:

  1. Completeness — do the KDEs exist at all? For each CTE (receiving, transformation, shipping) do you have the traceability lot code, the product identifier, the location, the date, and the quantity?
  2. Sortability — can you produce them electronically, filtered to one lot, without a manual project? A binder of PDFs is not sortable. A spreadsheet someone assembles by hand during the exercise is not 24-hour-defensible when the real event is a Saturday.
  3. Linkage — do the events actually connect end to end? This is the one that breaks. Can you follow one lot from the supplier's shipping event, through DC receiving, through unit receiving, through any in-store transformation — as a chain, not five disconnected record piles you join by hand?

Run the exercise as a real traceback: pick one lot code, start a timer, and require the answer to arrive as a filtered electronic record, not a narrative. Note every point where someone reaches for a phone or a login to another party's system. Those points are your map.

Why does the traceback break at the franchise boundary?

Because at the franchise boundary two things fail at once — and the second is the one nobody warns you about.

Failure one: the data changes owners. At a franchisee, the receiving record is contractually somebody else's to hand over. Your traceback stops being a query you run and becomes a request you make — to a different company, on their timeline, in whatever format they keep. Multiply by every franchise unit a lot touched and the 24 hours evaporates in coordination, not in querying.

Failure two — the structural one: the record can say a case arrived, but not who received it. This is not a franchisee discipline gap. It is a gap in the standard itself, and you can verify it against the public spec in ten minutes. EPCIS 2.0 §7.2.2 defines five event dimensions — what, when, where, why, how — and no performer. The party fields that exist are organization-grain — a company, a Party Global Location Number. So the standard fully answers "a company received this lot at this location." It has no field for the person or the handheld's agent that actually observed the scan. There is no Who box left blank — there is no box. That is precisely why "who received this at unit 4471" is answerable only by a phone call: the field to answer it in does not exist in the record, at either party.

So the franchise boundary is where two silences meet: the data crosses a company line and the one detail that would let you close custody across that line was never recordable in the first place. Training does not fix a missing field.

How do you make the traceback survive the boundary?

You give both sides the same event, in the same shape, keyed the same way — so there is nothing to reconcile across the boundary because both parties captured one fact, not two.

  • One canonical event per receiving, in the standard's shape. Each receiving becomes a single valid EPCIS 2.0 event using CBV 2.0's receiving business step, validated against GS1's own schema on capture. The KDEs are the event's own fields — you are populating GS1's schema, not inventing one.
  • Keyed to a GS1 identifier both sides already share. Because the identity in the mark normalizes to the same GTIN/lot key on both sides of the franchise line, the brand's event and the franchisee's event are about the same item without a mapping table between two systems.
  • Deduplicated by a standardized hash. When the same physical receiving is captured by both the franchise unit and the brand, the CBV 2.0 §8.9 event hash makes them resolve to one event instead of two disputed ones. The boundary stops being a reconciliation problem.
  • Append-only and owned by you. No service identity holds UPDATE or DELETE, and the record is not trapped in a reader vendor's cloud. What you hand the FDA is evidence you control.

And the performer gap — the missing Who — is the specific thing we are building to close: a conformant way to carry which worker or which agent observed the event, that still projects down to clean EPCIS 2.0 so it is losslessly the standard when a counterparty reads it. Same door, same key, whether a person or an agent did the scan.

Stated plainly, because the honesty rule is the point: that hosted record layer is a named entry in the open P0 ledger, and the performer grain is this platform's own authorial act. The capture spine passes 683/683 conformance tests, and its stateless doors are live: POST https://epcis.dev/translate, /validate and /hash. A build task with a named owner, said as one.

The payoff is concrete: when each receiving is one canonical, hash-keyed event that carries the performer, a lot-scope question is a query, not a fire drill — and that is the difference between a full recall and a lot-level withdrawal. The narrow withdrawal is worth more than the entire program the one time you need it.

A note on the deadline, so nobody sells you a moved clock

Get this exactly right, because it is falsifiable in one search and a deadline-urgency pitch reads as un-briefed. The FSMA 204 compliance date moved from January 20, 2026 to July 20, 2028. That extension was never finalized as a rule — it rests on the Continuing Appropriations Act of 2026 directing FDA not to enforce before that date — and FDA is actively soliciting further flexibilities (the May 28, 2026 Federal Register notice on lot-level traceability). Treat 2028 as a floor that de-risks the investment, not a gun to your head. The reason to close the recall gap now is operational: you never want a contamination scope answered in phone calls. The regulation is the backstop, not the business case.

Run the exercise, then fix the field

Run one honest mock recall: one lot, one timer, answer as a filtered electronic record, and mark every phone call. You will find two breaks at the franchise boundary — the data changing owners, and the missing Who. The first is solved by both sides holding the same standardized event; the second is the field the standard omits, and the one we are building to restore.

→ Put me on the seat list — your capture workspace is provisioned from the list, in order; one email when your seat is ready. Choose "Distributor" — the receive-hold-ship-on side of the handoff, the dock where your scan already lands.

This is the food-safety-hero companion to the pillar, where the reads land and why the record survives the boundary. If you also operate or supply grocery retail, the same mock-recall break shows up at the store back door — the grocery food-safety pillar covers the ICP sitting on both the FSMA receiving clock and the Sunrise 2027 lane at once.