For twenty years, “traceability” in an MES meant one thing: if a customer called about a bad part, could you find out what else was made with the same raw material lot, and could you find it fast enough to limit a recall. That’s a real capability, and most mature MES platforms do it well. It is also, it turns out, not the capability that regulators are now asking for. FSMA 204’s compliance date has come and gone, and the EU’s Digital Product Passport framework is moving from concept to concrete requirement ahead of its battery and textile rollouts. Both regimes assume something your traceability data model was probably never designed to do: hand structured, machine-readable records to someone outside your four walls, on demand, in a format they didn’t have to ask you to build.
That gap doesn’t show up in normal operation. It shows up the first time an auditor, a customs broker, or a large retail customer sends a request that doesn’t look like “pull up the genealogy report” — it looks like “send us the CTE records for these three shipments in the required schema.” That’s the moment plants are discovering the problem isn’t their data. It’s their data model.
Recall lookups and regulatory traceability are different problems
A classic MES genealogy model is built around the finished lot or work order as the anchor. You can walk backward from a finished good to consumed material lots, and forward from a raw material lot to everything it touched. That’s a tree, and it’s usually implemented as a set of parent-child consumption relationships tied to work orders — clean, relational, and entirely internal to your plant.
FSMA 204 doesn’t think in trees. It thinks in Critical Tracking Events (CTEs) — harvesting, cooling, initial packing, first land-based receiving, shipping, receiving, and transformation — each carrying a defined set of Key Data Elements (KDEs): traceability lot codes, location identifiers, quantities, dates, and reference document numbers. The FDA’s Food Traceability List rule is event-based, not batch-based. It expects you to be able to produce a discrete, timestamped record every time a covered product crosses one of those event boundaries — including events that happen at your suppliers’ and customers’ sites, not just yours.
The EU’s Digital Product Passport works on a related but distinct assumption: that product-level data — materials, origin, repairability, recyclability, compliance certificates — needs to be attached to a unique product identifier and made retrievable by anyone with the right access, potentially for the life of the product, not just the life of the manufacturing order. Battery regulation is the leading edge; textiles are next in line. Neither regime cares whether your ERP and MES agree internally on what a “lot” is. Both care whether you can externalize the record in a form a third party’s system can actually consume.
Where the models actually break
Three gaps show up again and again when plants run a real gap analysis against these requirements, rather than assuming their existing lot traceability “basically covers it.”
- Lot genealogy depth stops at the plant boundary. Most MES genealogy was designed to answer questions inside one facility or one corporate network. It rarely captures the upstream supplier’s lot code in a form that survives a receiving transaction cleanly, and it almost never captures what happens after goods ship — the downstream CTEs FSMA 204 requires you to receive from, or transmit to, trading partners. If your model can’t represent “this traceability lot code, as assigned by our supplier, maps to this internal lot” as a first-class, queryable relationship, you don’t have genealogy depth — you have an internal batch record with a supplier name field bolted on.
- Traceability is batch-based, not event-based. Many systems record consumption and production at the work-order or shift level: “this lot of finished product consumed these raw material lots, sometime during this run.” That’s adequate for a recall. It is not the same as a discrete, timestamped CTE record for a specific shipping or receiving event with its own KDE set. If your system can reconstruct a genealogy tree but can’t produce a standalone event record with a location identifier and reference document number attached, you’re going to be building that translation layer by hand, under deadline pressure, for every regulator or customer request.
- Everything lives in a proprietary or semi-structured export. A PDF genealogy report or a flat CSV pull satisfies an internal audit. It does not satisfy a regulator or a DPP data carrier that expects a defined schema — GS1’s EPCIS event model is the closest thing to a common language for CTE/KDE data, and DPP implementations are converging on structured, API-retrievable records tied to GS1 or similar global identifiers. If your “traceability export” is a human-readable report rather than a structured, interoperable data object, you have a reporting capability, not an interoperability capability, and those are not the same investment.
What to actually check before your next audit
Don’t start with software. Start with a walk-through of your own data model against the specific obligations, because the fix is different depending on where the break is.
- Pick one product and trace it as a sequence of discrete events — receiving, transformation, packing, shipping — and ask whether your system currently stores each of those as its own record with a timestamp, location ID, and reference document, independent of the work order. If the answer is “you’d have to reconstruct that from several tables,” your model is batch-oriented, not event-oriented.
- Check whether supplier and customer lot identifiers are captured as structured, linked data or as free text in a comments field. This is the single most common silent failure — the data exists somewhere in your ERP or MES, but it’s not modeled as a relationship, so it can’t be queried or exported reliably.
- Ask what your system produces when someone asks for a machine-readable export, not a report. If the honest answer involves an analyst and a spreadsheet, you have a manual workaround, not a compliance capability — and manual workarounds don’t scale past your first few DPP or FSMA 204 requests.
- Confirm your product and lot identifiers are aligned to a real global standard, whether that’s GS1 GTINs and serialized identifiers or an equivalent scheme your industry actually uses. Internal part numbers that mean nothing outside your ERP are the reason so many “traceability” integrations turn into custom mapping projects.
The uncomfortable part: this is an architecture decision, not a patch
It’s tempting to treat this as a reporting problem — bolt on an export utility, satisfy the next audit, move on. Some of that will genuinely help in the short term. But the deeper issue is that ISA-95-style MES data models were built around the plant as the unit of analysis, and these regulations treat the product as the unit of analysis, following it across companies and years. Closing that gap for real means extending your genealogy model to first-class supplier and customer events, moving toward event-based capture at the CTE level rather than batch-level summaries, and adopting an interoperable export format instead of a proprietary report as your system of record for external requests.
That’s a genuine architecture project, not a checkbox, and it varies widely in scope depending on how far your current model is from event-based capture. The plants that will be fine at their next audit or their next big customer’s data request are the ones treating this as a data model gap analysis now — not the ones waiting to find out the hard way what “produce your CTE records” actually means when someone asks for them in a format you don’t have.
This article was written with the assistance of artificial intelligence. While we aim for accuracy, the information may be incomplete, out of date, or incorrect, and should be independently verified before you rely on it for any decision. It is provided for general information only and does not constitute professional advice.
