You funded a case-level RAIN RFID rollout. Tags are going on corrugate, handhelds are scanning at the back door of the distribution center, and somewhere in the last budget review someone asked the question nobody had a clean answer to: once we read a case, where do the reads land — and when the FDA or a lawyer asks us to trace a lot, does that record answer in minutes or in phone calls?

That is the gap this page is about. The readers were the easy part. The record layer underneath them — the one that survives a franchise boundary, conforms to the standard your suppliers are already moving to, and belongs to you rather than a vendor's cloud — is the part that is still missing. We are building exactly that layer, in the open, against GS1's own EPCIS 2.0 and CBV 2.0 specifications.

The problem, in the words of the person who owns it

You are the Director of Food Safety or QA. You have run the 24-hour mock recall. You know the exact place it broke: the record shows that a case arrived at a DC — but never who received it, on which handheld, at which door. So the traceback stops being a query and becomes a series of phone calls, and each call crosses a franchise boundary where the data is contractually somebody else's to hand over.

Meanwhile the VP of Supply Chain and Distribution — the one who actually signed the RFID PO — is measured on receiving labor and inventory accuracy, not on recall time. The rollout was sold internally on efficiency. It landed you the reads. It did not land you a place to keep them, and it did not answer the custody question that keeps you up before an audit.

Two people, one deployment, one unanswered question: the reads exist and the record does not.

Where we come in

We are not a reader vendor and we are not a compliance-forms product. We build the event record that the reads are supposed to become — the layer that turns a scan at your dock into a durable, standards-conformant fact you can query later.

GS1 has not reviewed or endorsed what we build. The spine is built against the standard's own OpenAPI description and its own conformance vectors, rather than a reinvention of them.

Here is the plan, and it is deliberately small:

  1. A case scan becomes a valid EPCIS 2.0 event — validated against GS1's official JSON schema on the way in, not after the fact.
  2. The event carries a standardized identity — the CBV 2.0 §8.9 event hash — so the same physical receiving, captured by both a franchise unit and the brand, resolves to one event instead of two disputed ones.
  3. The record is yours, append-only — no service identity holds an UPDATE or DELETE grant, and the record does not live in a reader vendor's cloud you cannot withdraw it from.
  4. Recording an event is free. Capture never costs money and is never shown as a meter — policy, stated ahead of published terms. Revenue attaches to answers — traces, custody evidence, exception review — never to the act of writing an event down.

How fast should a FSMA 204 traceback / mock recall actually take?

The honest answer: fast enough that the elapsed time stops being the number you dread. FSMA 204's recordkeeping requirement is built so that a covered facility can produce the traceability records — the Key Data Elements for each Critical Tracking Event — in an electronic, sortable form within 24 hours of a request. Most operators who have run the exercise know the 24 hours is not the constraint; the constraint is that the record goes silent at the franchise boundary and the last mile is manual.

The point of a real event record is that a lot-level traceback becomes a query, not a fire drill. When each receiving is one canonical event keyed to a GS1 identifier, "where did lot X go and where did it come from" is a lookup — and the difference between a full recall and a lot-level withdrawal is exactly whether you can answer it at lot grain in minutes.

A note on the deadline, so nobody sells you a moved clock. 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 (Federal Register, May 28, 2026, lot-level traceability public meeting). Treat 2028 as a floor that de-risks the investment, not a gun to your head. Anyone pitching you a 2026 deadline is wrong, and it is falsifiable in one search. The reason to build the record layer now is operational, not regulatory — see below.

We're rolling out RFID in our restaurants — where should the read data live?

Not in the reader's cloud. That is the one place it should not live, because the whole value of a traceability record is that you can produce it on demand — to an auditor, to the FDA, to a franchisee, to a co-manufacturer — and a record you can be locked out of is not evidence you control.

The reads should land in a record you own, in the standard's own shape: EPCIS 2.0 JSON-LD, one event per Critical Tracking Event, each validated on capture. That way a dock scan and, in 2027, a lane scan land on one item without a mapping table between them — because the GS1 identifier in the 2D mark normalizes to the same GTIN key the EPCIS event list already uses. Your suppliers are re-marking cases and units on GS1's Sunrise 2027 timeline anyway, which makes 2026–2027 the cheapest window in a decade to change what gets captured at receiving — a timing argument, not a compliance one.

The executive gift — the gap you can check yourself in ten minutes

Here is the thing no vendor will tell you, because you can verify it against the public spec without us. EPCIS 2.0 §7.2.2 defines five event dimensions — what, when, where, why, how — and no performer among them. The party fields that do exist are organization-grain (EPCIS §7.3.6.4, CBV §7.4.3, §8.7.1 PGLN — a company, a Party Global Location Number). So a company doing a process is fully answered by the standard. A worker — or an agent — doing a task at the moment of the scan has no field of its own: the standard's Who stops at the company's GLN. That is precisely why your traceback crosses a franchise boundary and turns into phone calls: the record can say a case was received at a door; it cannot say which crew member or which handheld's agent observed it. Completing that grain is the company we are building. §7.2.2 · §8.7.1 — ten minutes, the specs are public, don't take our word for it.

The engineering ledger — what "written and passing locally" actually means

For the Director of Restaurant Technology who inherits every integration: the spine validates every captured event against GS1's official EPCIS 2.0 JSON schema, pinned by sha256 digest in PINS.json and gated in CI (EPCIS 2.0.1). Errors come back as RFC 7807 application/problem+json carrying the standard's own exception types. The CBV 2.0 §8.9 event hash is computed with GS1 Digital Link normalization and checked against OpenEPCIS reference vectors, so your hash matches what your counterparty computes. Supplier feeds in whatever they have — EPCIS 1.1 / 1.2 / 2.0 XML, CSV, vendor JSON — translate to EPCIS 2.0 JSON-LD with a per-job round-trip fidelity report. You can exercise it now: POST to https://epcis.dev/translate, /validate and /hash — 683/683 spine tests pass, and no conformance attestation has ever been issued. The hosted capture spine is a named entry in the open P0 ledger.

What are the KDEs and CTEs under FSMA 204 for a restaurant operator?

FSMA 204 is built around Critical Tracking Events (CTEs) — the points where a food on the Traceability List is received, transformed, shipped, and so on — and the Key Data Elements (KDEs) you must have on record for each: the traceability lot code, the product identifier, the location, the date, the quantity. For a multi-unit restaurant operator the CTEs that bite are receiving (at the DC and at the unit) and any in-store transformation.

Two things are worth being precise about:

  • A receiving CTE maps cleanly onto one EPCIS event. CBV 2.0 gives you the business step (receiving) and disposition vocabulary directly. The KDEs are the event's own fields. You are not inventing a schema; you are populating GS1's.
  • The KDE FSMA asks for and the thing your traceback actually needs are not the same. FSMA reaches the lot, product, location, date, quantity. It does not reach the performer — because, as above, the standard has no field for one. That is the structural gap, and it is why "who received this" is answerable only by phone call today. We do a worked read of exactly which of your KDEs and CTEs FSMA 204 reaches versus what your suppliers will actually send, plus the one exception that matters: the receiving scan where the case is recorded but no performer is.

How did Chipotle roll out RFID across its restaurants for food traceability?

This is the best-documented example in the public record, so it is worth stating exactly, with no embellishment. In December 2023, Chipotle went nationwide with case-level RFID across roughly 3,200 US restaurants and about 330 product categories, expanding to 19 distribution centers. The named vendors were Mojix (the software platform), Zebra Technologies (the handheld readers), and Avery Dennison Smartrac (the tags). Mojix's president is on the record attributing the program to "the compliance requirements of FSMA 204" — that regulation-to-spend claim is carried by a third party, not by us (RFID Journal, December 19, 2023).

That is the shape of a QSR doing this at national scale. What the public record shows Chipotle bought is the reading and the deployment software. What it does not settle is where the durable, standards-conformant event record lives — which is the layer this page is about.

For McDonald's, the public record supports a pilot and nothing more: a McDonald's ↔ Golden State Foods RFID pilot tracking fresh beef from manufacturer to restaurant, with Sue Fangmann (US Supply Chain Services Director, McDonald's) on the record in MIT Technology Review wanting to "create a golden digital thread of traceability" (MIT Technology Review Insights / GS1 US, October 30, 2023), and a GS1 US case study of the Golden State Foods plant side — RAIN RFID, case-level, pre-tagged corrugate, GS1 TDS 2 encoding, 100% encode success (February 9, 2024). We do not claim McDonald's US is rolling out RFID in production; the record does not support it, and anyone telling you it does is overclaiming.

Does RFID at receiving actually cut cost — or is it just compliance?

This is the question the economic buyer actually asks, and the honest answer leads with operations, not the regulation. The strongest public data point is McDonald's China with Cainiao — the "One Box, One Code" program, an RFID digital ID per package, reporting +30% receiving and inventory efficiency at production scale (China Daily / Cainiao, November 28, 2024). That is proof a QSR will fund this when someone brings a platform, and it is an efficiency number, not a compliance one. Add the Golden State Foods plant result — 100% encode success on pre-tagged corrugate — and the picture is consistent: the returns show up as receiving labor and inventory accuracy first, and recall-readiness is the de-risking floor underneath.

The implication for your record layer: the ROI justifies the reads whether or not the deadline ever hardens. The record layer is what converts those reads from an inventory count into an answer you can give an auditor — at no per-event cost, in a record you own.

What ships today, stated plainly

  • Live today, checkable by curl: POST https://epcis.dev/translate, /validate and /hash — the spine's stateless doors. No conformance attestation has ever been issued, and none is claimed.
  • The capture spine passes 683/683 conformance tests — schema-validated EPCIS 2.0 capture, RFC 7807 errors, the CBV 2.0 §8.9 hash against OpenEPCIS vectors, append-only storage, XML→JSON-LD translation with round-trip fidelity, and an MCP door so agents use the same interface and the same key as people.
  • The record layer you asked about — the hosted place your reads land — is a named entry in the open P0 ledger. A named build task, not a hedge.

See the dated, line-by-line ledger of built vs unbuilt at /what-ships-today.

Success looks like this

The next mock recall is a query, not a fire drill. The traceback resolves at lot grain in minutes, and it does not stop at the franchise boundary because both sides captured the same event and it carries the same hash. A contamination scope becomes a lot-level withdrawal instead of a full recall. The reads you already paid for finally became a record — one you own, in the standard your suppliers already speak, that answers the question an auditor asks without a single phone call.

Put me on the seat list

You told us where the reads from a deployment already in flight should land: in a capture workspace, provisioned from the seat list in order — the hosted record layer is a named entry in the open P0 ledger. Two doors, both real today. The deeper one: get the written read for your operation — the branching interview is live on this origin, and branch Q is the restaurant operator's own sequence; your address first under the one-message promise, then questions that branch on your answers, ending in a written read that locks. The lighter one: leave your side of the handoff and your address — your capture workspace is provisioned from this list, in order. One email when your seat is ready — one, not a drip campaign. Nothing else, ever — no newsletter, no sequence. If we stop working on this, you get one message saying so and your address is deleted. Either way it is one message. (The named human sender and the verified sending address are a launch gate — P0-V4 in the open P0 ledger; the message is not sent until both exist.)

→ Put me on the seat list (Choose "Retailer or point of sale" — the side of the handoff where, in 2027, a lane scan becomes an event that lands on the same item your dock scan already does.)

If you want a conversation, ask for one — but read first. We answer in writing. We take at most five conversations a month, only when you ask for one, and only after you already have the written read. For an operator with a funded rollout and reads already landing nowhere, one of those conversations is about exactly one thing: the data layer under the deployment you already funded. The demo is a curl — POST to https://epcis.dev/validate — and no attestation is ever claimed.

The same spine, from other angles

  • The developer's lens → epcis.dev — the integration-class work your restaurant-technology team inherits (onboard any supplier feed with translate and validate, runnable locally, no account), described from the engineering side.
  • The food-safety sibling → if you also operate or supply grocery retail, the grocery pillar covers the one ICP that sits on both clocks — the Sunrise 2027 lane and FSMA 204 receiving at the same time.