Designing a Food Traceability Event Model That Survives Real-World Handoffs

Hanieh Khanmohamad — Tue, 10 Nov 2026 11:42:10 +0000

A dashboard that says “shipment delivered” is not a traceability system. During a food recall, the useful questions are much harder: Which ingredient lots were combined into this finished batch? Where did those transformations happen? Which customers received the affected products?

A system can answer these questions without requiring an elaborate blockchain or a large data platform. What matters first is a trustworthy model of events and relationships.
An event is not a current inventory balance
An inventory table tells you what you believe is in a warehouse now. A traceability event records something that happened to a product or lot at a particular time and location.

The GS1 EPCIS standard describes visibility data using events that help answer what, when, where, and why. EPCIS 2.0 also supports contextual observations such as temperature. In practice, partners need a shared vocabulary as much as they need a shared API.

For a minimal prototype, begin with six event categories:

Created — a production or receipt lot is assigned an identity.
Packed — units are grouped into cases, pallets, or containers.
Shipped — custody moves from a defined location.
Received — another location acknowledges the movement.
Transformed — one or more input lots become one or more output lots.
Disposed — stock leaves the usable chain through destruction or another recorded disposition. These are illustrative application events, not an exhaustive or official list of EPCIS event types or of the FDA's Critical Tracking Events. Start with a small, explicit record Here is an intentionally simplified event. It is not an EPCIS-compliant JSON document. A production integration should adopt the official GS1 data model and controlled vocabularies. { "event_id": "evt-2026-0114", "event_type": "received", "occurred_at": "2026-11-09T08:42:00Z", "lot_id": "LOT-PEAR-204", "product_id": "SKU-PEAR-BOX-10KG", "location_id": "WH-02", "quantity": 125, "unit": "box", "previous_event_id": "evt-2026-0113", "operator_id": "team-03" } The field names are less important than their meanings. Document the unit of measure, the identity of each organization, and the distinction between a product identifier and a particular production lot. If a receiver measures kilograms while a shipper records cases, preserve both measurements and the conversion rule rather than quietly rewriting history. Five implementation decisions that make or break a recall
Keep an append-only audit trail. A corrected quantity should generate a new correction record tied to the earlier event. An update that silently replaces the original record may conceal precisely the discrepancy investigators need to understand. This does not mean the entire application must use event sourcing; the audit history just needs to remain inspectable.
Model transformations as relationships. Suppose flour lots F-17 and F-18 are used in production batch B-55. A scan of the finished batch is not enough. You need explicit edges from both inputs to the output, including measured or estimated quantities. The resulting graph allows a query to move backward toward suppliers or forward toward customers.
Use globally unambiguous identities where necessary. Human-readable names such as “Warehouse 2” are prone to collisions. Keep identifiers stable across organizational boundaries, and map partner-specific codes to a canonical identity with documented ownership.
Treat time and sensors carefully. Store timestamps with offsets or in UTC, preserve the observed local context, and record device identity and calibration metadata for temperature readings. Missing samples are unknown, not evidence that the cold chain remained within limits.
Protect commercially sensitive data. A downstream buyer may need confirmation that a lot passed an inspection; it rarely needs unrelated supplier prices or employee records. Implement field-level permissions and log access to shared records.
A recall drill is a better test than a dashboard demo
Pick a hypothetical finished food lot and ask the application to return the full chain of input lots, processing events, storage locations and customer shipments. Time how long it takes, then reverse the query from an input lot and identify every affected output lot.

Try four failure cases: a scanner working offline, a late data upload, a duplicate receiving record, and a partner using an unexpected unit of measure. A credible system must explain gaps rather than return a confident-looking but incomplete answer.

Useful metrics include time to reconstruct a lot's history, percentage of shipments with complete handoff records, and number of unresolved identity mismatches. “We collected a million events” is not a safety metric.

In the United States, the FDA's Food Traceability Rule also requires specific Key Data Elements (KDEs) around Critical Tracking Events (CTEs) for certain foods. As of November 2026, the agency states that Congress directed it not to enforce the rule before July 20, 2028. A prototype data model should never be mistaken for a compliance assessment: map each relevant legal requirement independently. See the FDA's rule overview.
The problem continues beyond the API
Food traceability is ultimately a cooperation problem. One organization can build a flawless event store and still fail if a carrier, co-packer or retailer cannot match its identifiers or deliver its records during an investigation.

For readers examining the commercial and regional dimensions of food production, distribution and logistics, Mazehnameh provides Persian-language food supply-chain analysis. The technical architecture and the operational reality should inform one another.

Start with one product family and a small set of partners. Rehearse both forward and backward tracing. Add features only after a real gap appears in the drill.
References and further reading

GS1 — What is Electronic Product Code Information Services (EPCIS)?
GS1 — EPCIS 2.0 standard
US FDA — Food Traceability Rule overview Editorial disclosure: This educational article was drafted with generative AI assistance. It contains a simplified illustrative record, not production software or legal compliance advice. Subject-matter review is recommended before implementing its design.

DEV Community: Mazehnameh

Designing a Food Traceability Event Model That Survives Real-World Handoffs