Every food-safety leader who has sat through a serious audit knows the moment the exercise turns: not when the question is asked, but when the answer's provenance is asked. Where did this number come from? Who prepared this export? What happened between the system of record and this spreadsheet? Every step between the record and the answer is a reconciliation step, and every reconciliation step is a credibility tax you pay in the room, under time pressure, on your worst day.
The architecture that eliminates the tax is simple to state: the answer you show is a view computed over the record itself, not an export prepared from it. Not simple to bolt on — but simple to state, and checkable.
The export problem
The typical trace-back answer travels a long road before an auditor sees it. Events live in a capture system; an analyst extracts them; a spreadsheet joins them to a distribution feed; a slide summarizes the spreadsheet. Four artifacts, three handoffs, each a place where a filter was applied, a row was dropped, a date was retyped. The auditor cannot re-derive the slide from the record, so the exercise becomes about trust in your process — which is exactly the conversation you did not want to be having.
One catalog, two doors
Our answer to that is structural. Every event is stored once, in one catalog. The developer-and-agent door — epcis.dev, open source — queries that catalog directly. The executive door — the trace views, the custody evidence, the exception dashboards this brand sells — is computed over the same catalog. There is no second store, no nightly copy, no reporting database that can drift. Recomputability is structural, not audited: there is nothing separate to audit because there is nothing separate.
The audit exchange, replayed
Here is the exchange as it runs with one substrate and two doors. The trace question is the standard one — this lot, this window, show me receiving.
The answer as shown — the trace view, as the room sees it (illustrative):
| When (UTC) | Step | Location | Lot | Observer |
|---|---|---|---|---|
| 07-28 09:14 | shipping | Supplier DC, Riverside | 4521 | attested |
| 07-28 21:40 | receiving | Your DC 7 | 4521 | attested |
| 07-29 06:02 | shipping | Your DC 7 | 4521 | attested |
| 07-29 11:55 | receiving | Store cluster, 46 sites | 4521 | attested |
The same answer, re-derived — the auditor (or your own engineer, or an agent seat) runs the query at the developer door against the identical catalog:
POST /queries — EPCIS 2.0 query interface { "query": { "EQ_bizStep": ["receiving"], "MATCH_epcClass": ["urn:epc:idpat:sgtin:0614141.107346.*"], "GE_eventTime": "2026-07-28T00:00:00Z" } }
Same events, same count, same timestamps — necessarily, because both renderings are computed from one store. The exchange stops being "trust our export" and becomes "re-run it yourself." A regulator will rarely take you up on it. The fact that they could changes the posture of the entire audit.
Two details make the re-derivation meaningful rather than theatrical. Each event's identity is its CBV 2.0 §8.9 hash — computed from content, never assigned — so the re-derived set is checkable event-by-event against what was shown; and each event carries its who, the attested observer, distinct from capturedBy, the warrantor account. When the auditor's follow-up is "who received this case," the record answers with a performer, not with the name of your company — the difference verifiable without joining walks in full.
Why this cannot be bolted on
A vendor whose dashboard reads from a reporting copy can promise reconciliation discipline; they cannot promise the absence of reconciliation. The property you want is decided when the architecture is decided: either the answer layer and the query layer share a substrate or they do not. Retrofitting it means rebuilding the store — which is why it appears in procurement one architecture too late, and why the time to ask is before the rollout in flight picks its data layer. For the QSR-specific version of that decision, the RFID food-traceability pillar is the longer read.
The one question
Ask any vendor: "Is the dashboard computed from the same store the API reads?" Then ask them to prove it the way we just did — one answer, two doors, zero reconciliation. If the demonstration requires a caveat, you have your answer.
Your last mock recall's elapsed time already told you where the record breaks; the franchise-boundary read maps that failure. When you want the audit-day architecture instead, get started — the interview branches for restaurant operators and their distributors, and the trace-back questions are its spine.