Every "RFID architecture for QSR" explainer you will find is really a shopping list dressed as a diagram: tags, readers, middleware, done. That map is not wrong. It is just incomplete in exactly the place that matters, and the incompleteness is load-bearing — it is why chains finish a rollout with millions of reads and still cannot answer a traceback without picking up the phone.

So let's walk the stack honestly, using the one national deployment that is actually documented on the public record by name, and then name the fifth layer the shopping list leaves off.

What are the layers of a QSR RFID stack?

There are four layers everyone maps, and a fifth almost no one does.

Layer 1 — Tags (the identity carrier). A passive RAIN RFID inlay on or in each case of corrugate. Its job is to carry a globally unique identity — a GS1 key — that survives handling and reads at distance without line of sight. The decisive design choice is where the tag gets encoded: at the supplier's plant, on pre-tagged corrugate, verified before it ships. Encode-at-source is what makes the rest of the stack trustworthy.

Layer 2 — Readers (the observation points). Handhelds in associates' hands and fixed portal readers over dock doors and receiving lanes. This layer converts physical presence into a raw read event — "antenna 3 saw tag EPC X at 09:42."

Layer 3 — Deployment / edge software (the floor workflow). The middleware that manages the reader fleet, filters and de-duplicates the raw read storm, and turns it into something a receiving associate can act on: a case count, a match-to-PO, an exception flag. This is the layer that makes RFID usable on the floor day to day.

Layer 4 — The inventory / operations system (where reads become counts). Reads roll up into on-hand inventory, cycle-count automation, first-expiry-first-out enforcement, and the receiving KPIs the economic buyer is measured on. This is where the receiving-and-inventory ROI is realized.

Layer 5 — The event record (the layer everyone forgets). More on this below — because layers 1–4 are what the vendors sell, and layer 5 is what the auditor asks for.

What did Chipotle's public RFID stack actually use?

This is worth stating precisely, because it is the one QSR RFID stack whose components are named on the public record, and it lets us map the four layers to real products instead of hand-waving.

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 components were Avery Dennison Smartrac (the tags — layer 1), Zebra Technologies (the handheld readers — layer 2), and Mojix (the software platform — layer 3). Mojix's president is on the record attributing the program to "the compliance requirements of FSMA 204" (RFID Journal, Dec 19, 2023).

Notice what that public record settles and what it doesn't. It settles the reading and the deployment software — layers 1 through 3, and by extension the inventory workflow of layer 4. It says nothing about where the durable, standards-conformant event record lives. That is not a gap in the reporting; it is a gap in how these stacks are assembled. The record was never a layer anyone bought, because no vendor in layers 1–3 sells it as their product.

(One deliberate omission: this is not a vendor bake-off, and we are not going to route you to a competitor's marketing. The Chipotle stack is cited because it is the single fully-named public example — a map, not a recommendation.)

Why doesn't the deployment software count as the record?

Because layers 3 and 4 are built to answer "what do I have right now?" — a live inventory question — and that is a fundamentally different job from "what happened to this specific lot, where did it go, and who observed it?" — a durable custody question.

Deployment software optimizes for the present tense. It filters the read storm, de-dupes, and hands the floor a current count. It is allowed to forget — in fact it is designed to forget, because yesterday's raw reads are noise to a live inventory view. The record layer optimizes for the past tense and is not allowed to forget: it needs one canonical, immutable event per Critical Tracking Event, in a shape a counterparty and an auditor both accept, retained for the life of the traceability obligation.

Three properties make the difference concrete:

  • Standard shape, not vendor shape. A record you can hand to a supplier, a franchisee, the FDA, or a co-manufacturer has to be in the standard's shape — EPCIS 2.0 JSON-LD, one event per CTE, validated against GS1's own schema on the way in — not a proprietary reader-cloud export that means nothing outside that vendor's tenant.
  • Append-only and yours. No service identity holds an UPDATE or DELETE grant, and the record does not live in a cloud you can be evicted from. A custody record you can be locked out of is not evidence you control.
  • One event, not two disputed ones. When the same physical receiving is captured by both a franchise unit and the brand, a standardized event hash (CBV 2.0 §8.9) makes both sides resolve to one event instead of two that disagree. Deployment software has no reason to compute this; a shared record layer has every reason to.

The layer everyone forgets — and the field even the standard forgets

So the fifth layer is the event record, and building it exposes one more gap — this one in the standard itself, and you can check 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 do exist are organization-grain (a company, a Party Global Location Number). So the standard can record that a case was received at a door; it cannot record which crew member, on which handheld, actually observed it. A company doing a process is fully answered. A worker — or an agent — doing a task at the moment of the scan is structurally absent. That is exactly why a traceback crosses a franchise boundary and turns into phone calls: the record goes silent on the one thing you need to close custody. Completing that performer grain — conformantly, so it still projects down to clean EPCIS 2.0 — is the layer we are building.

Stated plainly: that hosted record layer is a named entry in the open P0 ledger. The capture spine — schema-validated EPCIS 2.0 capture, RFC 7807 errors, the CBV 2.0 §8.9 hash checked against reference vectors, append-only storage, and feed translation with a round-trip fidelity report — 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, not softened copy.

If you are the person who inherits every integration on this rollout, the useful mental model is: buy layers 1–4 from whoever runs the deployment; own layer 5 yourself, in the standard, so your reads become a record no vendor can hold hostage.

→ 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 stack-map companion to the pillar, where the reads land and why the record layer is the one you own.

<!-- ═══════════════════════════════════════════════════════════════════════════ ARTICLE P2-c TARGET SLUG: