Here is the fact that reorganizes every FSMA 204 program plan once a Director of Food Safety sees it: your compliance is decided upstream. The rule asks you to keep Key Data Elements at receiving and shipping. Whether you can is a function of what your suppliers emit — and the delta between the two is not a mystery to be discovered in 2028. It is measurable today, supplier by supplier, and measuring it is the highest-leverage half-day in the whole program.
The KDE set, stated plainly
Strip the vendor gloss and the rule's receiving obligation is short. For a covered food, receiving is a Critical Tracking Event, and you must keep — sortably, electronically — the traceability lot code, the product identifier and description, the quantity and unit of measure, the shipping and receiving locations, and the date of receipt. Shipping CTEs mirror the set from the sender's side, and transformation links the input lots to the new one.
Every element is trivial on its own. The project is that each one must arrive — on the case, in the message, or both — from suppliers whose systems you do not run.
The three supplier postures, and what each can actually emit
Across a real QSR supplier set, data postures cluster into three shapes. The gap table below is the exercise worth running against your own top-20 suppliers this quarter:
| Receiving KDE | Posture A — case-level RFID, GS1-encoded | Posture B — ASN-only | Posture C — paper |
|---|---|---|---|
| Traceability lot code | On the case, machine-readable at the dock | In the ASN if mapped; not readable on the case | On a COA or invoice, keyed by hand later |
| Product identifier | GTIN in the tag encoding | GTIN or internal item number in the ASN | Description text |
| Quantity / UoM | Derived from case reads | Stated per shipment, unverified at case grain | Stated, unverified |
| Ship-from / ship-to | Derivable per case | Per shipment | Per shipment, sometimes |
| Date of receipt | Stamped at the read point | Stamped when someone confirms the ASN | Whenever the paperwork is filed |
Posture A is not hypothetical. The best-documented public example is GS1 US's Golden State Foods case study (February 9, 2024): case-level RAIN RFID at the Opelika, Alabama protein plant, pre-tagged corrugate, GS1 Tag Data Standard 2 encoding carrying the production date, and a 100% encode success rate — GS1 US's figure, on GSF's line, serving what the study calls only "a leading QSR customer." That is the ceiling of supplier posture on the public record, and it exists because one customer's program made it exist.
Posture B is your realistic median — and note what the table shows: an ASN says what the supplier intended to ship. It is a business document, not an observation, and nothing at case grain verifies it at your dock. The document-versus-event distinction, and why a trace should carry both, is its own read: ASN and PO context in traces.
Posture C is the long tail, and it is where a four-day traceback lives.
The gap is a grain problem, not a willingness problem
The instinct is to treat the gap as supplier recalcitrance. Mostly it is not. A supplier whose systems run at shipment grain cannot emit lot-per-case data by trying harder — the information is destroyed before it reaches the message. The KDE set is quietly a data-grain requirement: lot, at case level, bound to a receiving observation. Which means fixing the gap is a re-marking and capture project, not a compliance-letter project — and re-marking projects have a natural cheap window.
That window is now. Your suppliers sell to grocers, and GS1's Sunrise 2027 programme expects retail POS to scan and process 2D barcodes by end of December 2027 — so the same suppliers are already re-marking cases and units on that timeline. Asking a supplier to carry lot in a mark they are redesigning anyway is a small ask; asking them to redesign a mark for you alone is a large one. The timing argument is worked through in the pillar, RFID and food traceability for restaurants.
Measure it during the wave
The program move, concretely: for each covered supplier, capture one week of actual receipts through visibility.cloud's supplier-feed intake — it accepts what the supplier actually has, whether that is EPCIS event data in 1.1, 1.2, or 2.0 form, an ASN feed, or a structured export — and score each against the KDE table. The intake normalizes every posture into one event record, so the gap report falls out as a query, not a consulting engagement: which suppliers are receiving-complete today, which are one mapping away, and which need the re-marking conversation. (The translation engine underneath is the open developer surface at epcis.dev, where the same validation is a door you can point at without talking to anyone.)
What "receiving-complete" looks like as evidence
The end state is not a checkbox that says "compliant." It is a record where any named lot resolves, in seconds, to a sortable set of receiving events — each carrying the lot, the GTIN, the quantity, both locations, the date, and the who: the attested observer who received it, held distinct from capturedBy, the warrantor account behind the capture. That last column is the one no supplier posture in the table above provides and no incumbent record has a field for — and it is the difference between a record that answers a traceback and a record that starts a phone tree, as the worked timeline in the anatomy of a mock recall shows hour by hour.
Suppliers decide your ceiling. The gap decides your project. Measure it while the wave makes closing it cheap.
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 supplier set and receiving paths, ending in a written read for your situation. The final step locks.
→ Start the interview — it is questions, not a demo.