Most FSMA 204 guides explain what the law says. You have read those.
This one explains what your data model needs to look like.
If you are building toward FSMA 204 compliance, at some point you will hit this question: how do we capture a Critical Tracking Event in a system that can answer an FDA traceback request in 24 hours? The law names CTEs and KDEs. Your ERP does not speak that language. And EPCIS is in every vendor conversation but nobody draws the actual mapping.
A note on timing: the FDA extended the compliance deadline by 30 months, from January 2026 to July 20, 2028. That gives teams more runway. It does not change what you need to build. Supply chain coordination takes longer than most teams expect, and the FDA expectation has not moved: complete lot-level history in 24 hours.
I have worked on EPCIS implementations for food supply chains. Here is the mapping your team needs.
FSMA 204 is a data mandate, not just a recordkeeping rule
Section 204 of FSMA requires electronic traceability records for foods on the Food Traceability List (FTL). The FTL covers high-risk categories including leafy greens, fresh herbs, melons, tomatoes, peppers, cucumbers, sprouts, shell eggs, nut butters, fresh-cut produce, finfish, smoked finfish, cheeses, and tropical tree fruits. The full list is on the FDA site. Map your catalog against it carefully, because scope varies more than people expect.
The rule is clear on what you need to capture: Critical Tracking Events and their Key Data Elements. It also sets a hard retrieval deadline. Within 24 hours of an FDA request.
Twenty-four hours to hand over a complete lot-level history. Not 24 business hours. 24 hours. That is a query problem. Not a compliance problem.
The FDA does not prescribe EPCIS. But EPCIS is the only widely adopted, standards-based event model that maps cleanly onto the CTE structure. Every CTE in the FSMA rule translates directly into an EPCIS event type. Every KDE field maps onto an EPCIS standard field or a well-defined extension.
If you build your traceability layer on EPCIS, you are not building a custom schema that only your team understands. You are building on a standard your suppliers, co-manufacturers, and distribution partners can connect to.
What are CTEs and KDEs?
CTEs are the defined moments in your supply chain that require a record. The FDA final rule defines seven:
- Harvesting (for produce and farmed seafood)
- Cooling (before initial packing, where applicable)
- Initial Packing (of a raw agricultural commodity, other than fish received from a fishing vessel)
- First Land-Based Receiving (of food obtained from a fishing vessel)
- Receiving
- Transforming (processing, packaging, repackaging)
- Shipping
Not every CTE applies to every operator. If you are a food processor buying from growers, your practical scope is Harvesting (your suppliers’ obligation, but your data gap), Receiving, Transforming, and Shipping. Seafood supply chains add First Land-Based Receiving. Fresh produce packers add Cooling and Initial Packing.
Each CTE has mandatory KDEs. These are the specific data fields required at each event: traceability lot code, quantity and unit of measure, location identifier, date and time, and a reference to the previous source traceability lot code.
That last field is the one teams miss. The previous source reference is what creates the lot linkage chain. Without it, the FDA cannot walk backwards through your supply chain to find the contamination source.
A traceback starts from an illness cluster. The FDA pulls lot codes from the retailer. They trace those lots to your distribution center, back through your facility, back to the grower. Every step depends on the previous source KDE in the receiving event at that step. One missing link, and the traceback stalls.
Most companies that fail an FDA traceback request do not fail because they did not record events. They fail because they recorded events without all the required KDEs.
Specifically, the previous source lot code is missing. It gets skipped when a supplier lot codes do not match your internal batch numbering system.
That is the gap to close first.
Mapping CTEs to EPCIS event types
EPCIS 2.0 defines five event types:
- ObjectEvent: something happens to a set of objects. A lot is received, shipped, or observed.
- AggregationEvent: objects are grouped. Cases are packed onto a pallet.
- TransformationEvent: inputs are consumed and outputs are produced. Ingredients become a finished product.
- AssociationEvent: objects are linked to a physical location or asset.
- TransactionEvent: objects are linked to a business transaction: a purchase order, invoice, or despatch advice.
The first four map directly onto FSMA 204 CTEs. TransactionEvent is out of scope for the CTE mapping itself, but matters if you want to connect your traceback records to commercial documents. Useful context when the FDA comes asking.
Here is the CTE-to-EPCIS mapping:
Harvesting, Cooling, Initial Packing, and First Land-Based Receiving all map to ObjectEvent with action=ADD. These are genesis records: the moment a lot enters the traceability chain for the first time. bizStep=harvesting for the farm event, bizStep=commissioning for initial packing or first land-based receiving. The readPoint is the farm or facility GLN. The lotNumber in the quantityList carries the traceability lot code assigned at origin.
Receiving maps to ObjectEvent with action=OBSERVE and bizStep=receiving. You are recording the arrival of existing lots at your facility. The epcList contains the lot codes received. The readPoint is your receiving location GLN. The sourceList carries the shipper GLN, which is your previous source reference. (One edge case: First Land-Based Receiving of fish — the first point at which the lot enters the traceability chain — uses action=ADD instead, since the lot is being introduced to the system for the first time.)
Shipping maps to ObjectEvent with action=OBSERVE and bizStep=shipping. If you are shipping palletised cases, use AggregationEvent instead. The AggregationEvent captures the parent pallet EPC and the child case EPCs together. Either way, the destinationList carries the receiver GLN.
Transforming maps to TransformationEvent. This is the most important event type for food processors to get right.
The TransformationEvent takes an inputEPCList (the raw material lot codes consumed) and an outputEPCList (the finished product lot codes produced). A bag of chopped romaine might contain lettuce from three growers. The TransformationEvent ties all three input lot codes to the one finished product lot code. When the FDA traces a contaminated input through your facility, the TransformationEvent tells them which finished product lots are affected. And which grower to go to next.
KDE mapping is straightforward for most fields. eventTime captures date and time. readPoint and bizLocation capture the location GLN. lotNumber and quantity sit in the quantityElement within quantityList. The previous source lot code maps to the sourceList on Receiving events.
Some FDA-specific fields do not have a native EPCIS equivalent. These go into the ilmd (Instance/Lot Master Data) extension block. Common examples: reference document number, entry number for imports, and the harvesting company contact information for the Harvesting CTE.
What your EPCIS repository needs to support FSMA 204 compliance
A spreadsheet is not a repository. A WMS with lot tracking is not a repository. You need a system built for event storage and lot-level querying.
Four things matter.
Persistent event storage with lot linkage across the chain. Every event must store its full EPC list intact. Lot codes must be consistent across events. If your receiving event records LOT-2024-0781 but your shipping event records 0781-MARCH, the chain is broken. The FDA query cannot link them.
A query interface that answers in under 24 hours. This means indexed lot-level queries, not batch report generation. The FDA does not want a report. They want the full event history for a given lot, from Growing through to your shipping dock. That query needs to run in seconds.
EPCIS 2.0 support. EPCIS 1.2 uses XML. EPCIS 2.0 supports JSON-LD, which is what modern integrations expect. The FDA has not mandated 2.0, but any repository you evaluate now should support it. EPCIS 1.2 is still in production use across the industry, but the trajectory is clearly toward 2.0 and JSON-LD. Building on 1.2 today means a migration in the not-too-distant future. Evaluate accordingly.
A supplier onboarding path. Your compliance is only as good as the weakest upstream link. If your leafy greens grower cannot submit EPCIS events, your Harvesting CTE records are missing. Most suppliers will not have a full EPCIS integration on day one. You need a path for them: a portal, a structured file upload, a simple API connector.
Common implementation mistakes
Recording your events but missing supplier KDEs. You build a clean receiving event. But the lot code in your receiving record does not match the traceability lot code on the grower certificate of conformance. The FDA has your event but cannot link it to the farm. The previous source reference is broken.
Using internal batch IDs instead of GS1-compliant lot codes. Your ERP assigns batch numbers for internal tracking. Those are not GTINs. They are not globally unique. When an FDA traceback crosses company boundaries, each company lot codes need to be machine-readable and interoperable. Internal batch IDs work inside your walls. Nowhere else.
Treating EPCIS as a reporting layer. Some teams pipe their EPCIS repository from their ERP as an end-of-day batch export. That creates event gaps. If the FDA requests a traceback at 2pm for events that happened at 9am and have not exported yet, you have failed before the 24-hour clock has even started. > EPCIS needs to be an operational data layer. Events captured at the moment they happen.
No TransformationEvent for co-manufacturing and repacking. If a co-manufacturer or third-party packer handles your product, they are responsible for the Transforming CTE. But if they are not capturing it in EPCIS, the gap is yours to explain during a traceback. Co-manufacturer EPCIS integration is not optional. It is the most common missing link I see.
Where Brevitaz fits
The Brevitaz traceability platform is built on OpenEPCIS, the open-source EPCIS 2.0 implementation originated and led by benelog GmbH. Brevitaz is a core contributor to the project, specifically the high-velocity, low-latency event ingestion layer. We also designed and built a Food Traceability Platform operated by GS1 Germany and Benelog GmbH, which runs across 770+ enterprises in 30 countries across Europe. The FSMA 204 platform is built on those same patterns, applied to the US compliance context.
The repository natively captures all five EPCIS 2.0 event types: ObjectEvent, AggregationEvent, TransformationEvent, AssociationEvent, and TransactionEvent. FSMA-specific KDE extensions are built into the data model, not bolted on.
We built a CTE/KDE validation layer that checks events at capture time against FSMA 204 requirements. If a mandatory KDE field is missing when an event is submitted, the system flags it before the event is stored. You do not discover a missing previous source reference during a traceback. You discover it at submission, when you can still fix it.
The FDA query interface runs a full lot traceback in under 60 seconds. We tested this on supply chains with millions of events. The index is built for lot-level lookups.
The platform deploys on-premise. Your food safety data stays in your own infrastructure. You control the query logs. When the FDA sends a request, you run the query from your system and hand over the results.
The supplier portal lets upstream partners submit EPCIS events without a full EPCIS integration. A grower fills in a structured form for their Harvesting CTE. A co-packer uploads a CSV. It maps to valid EPCIS events on the backend. You get a complete lot history without requiring every tier-2 supplier to have a traceability platform.
Getting started: July 2028 deadline, but the clock is already running
Four steps. Do them in this order.
Identify your FTL products. Not everything you handle is in scope. The Food Traceability List is specific. Map your product catalog against the FTL categories. Some companies find that 20% of their SKUs are in scope and 80% are not. Do not build a traceability system for your entire portfolio before you know exactly what needs to comply.
Map your current recordkeeping to CTEs. Look at what data you capture today at each supply chain step. Compare it against the required KDEs for each CTE. Most companies find two gaps: the Transforming CTE (especially at co-manufacturers) and the Harvesting CTE (because farm data lives with the grower, not with you). Finding the gaps now costs far less than finding them during an FDA request.
Choose an EPCIS repository that validates KDE completeness at capture. This is the most important decision you will make. A repository that accepts incomplete events and lets you fix them later is a compliance liability.
Validation at capture, not at audit.
Run a mock FDA traceback before go-live. Pick a finished product lot on the FTL. Pull the full event history: Harvesting, each Receiving step, any Transforming events, and Shipping records through to the retailer. Can you produce that history in 24 hours? Can you trace it back to the farm? Run this with real production data, not synthetic test records. If you can complete it cleanly, you are ready. If you cannot, now you know exactly where to fix it.
The question I keep asking teams that have been through a real FDA mock traceback: when you ran it for the first time, what was the KDE field you discovered was missing?
In my experience building these systems, it is almost always the previous source lot code from a supplier, because the supplier lot numbering system did not match what the receiving team entered. But I hear different answers from people deeper in food operations than I am. What did you find?
