A customer recall request arrives at 2:15 PM on a Thursday. The quality assurance manager needs to know: which finished goods shipments contained components from supplier lot 24B-0091, which received a quality hold three days after delivery but after partial consumption on the production floor? In a facility without structured lot traceability, answering that question takes a team of three people, four information systems, and somewhere between half a day and two days. In a facility with a well-designed traceability data model, it takes a single database query.
The difference is not primarily a technology choice — it is a data model choice made during system design, often years before the recall event that tests it. This article walks through the core entities, relationships, and recording points that define a functional lot genealogy system for discrete manufacturing, with specific attention to where the model typically breaks down in practice.
The Core Data Model: Four Entities
A minimal but complete lot traceability model for discrete manufacturing requires four entity types: Material Lots, Work Orders, Production Events, and Outputs.
Material Lots represent incoming materials at the level of granularity your traceability requirement demands. For IATF 16949 automotive supplier compliance, this is typically the supplier's lot or heat number, received at goods-in. For ISO 9001 general compliance, you may have more flexibility. Each Material Lot record carries: your internal lot ID, the supplier lot reference, material type, quantity received, goods receipt date, inspection status, and storage location.
Work Orders represent a planned production run: a defined quantity of a specific product, to be produced on a specific line or cell, within a planned time window. A Work Order is the bridge between the planning system (ERP) and the execution layer (your production floor). Each Work Order must reference which Material Lots have been issued to it — this is the consumption record that makes downstream traceability possible.
Production Events are discrete operations performed during a Work Order: a specific machine operation, an inspection checkpoint, a sub-assembly step. Each Production Event records the machine ID (and its current configuration or tool/die set), the operator or workstation ID, the start and end timestamp, and any process parameters logged (temperature, force, speed). This is the layer that most systems underinvest in, because it requires PLC integration or operator input at each operation — and it is also the layer that determines whether you can trace a quality escape to a specific machine, shift, or tool state.
Outputs represent finished units or assemblies, each carrying a unique identifier (serial number or output lot) that links back to the Work Order that produced it, and by chain, to the Material Lots consumed and the Production Events performed. Shipment records then link Output IDs to customer order line items and shipping dates.
Where the Model Breaks in Practice
Most traceability failures in discrete manufacturing are not technology failures — they are data capture gaps. The model is logically correct on paper, but a specific recording point was skipped, approximated, or filled in after the fact. There are three common break points.
Partial lot consumption without split records: A Work Order issues 500 units from Material Lot A. Midway through the run, the lot is exhausted and 120 units come from Material Lot B. If the system does not record a lot changeover event mid-run — because it requires a manual entry that the line operator did not complete — all 500 output units are traced to Lot A. The 120 units that consumed Lot B material are invisible in the traceability system. This is a common scenario with granular materials (fasteners, seals, packaging inserts) where lot changeover happens frequently and the recording friction is high relative to the perceived importance.
The mitigation is poka-yoke (ポカヨケ) at the lot changeover point: either require a barcode scan to confirm material lot identity before the next unit runs, or configure the production system to hold the line if a lot changeover is not confirmed. Both approaches require upfront engineering work, but they eliminate the category of error that makes a recall query produce incorrect results.
Work order vs. actual timing mismatch: A Work Order is planned for 8 hours. The actual production run spans two shifts and takes 11 hours due to a minor equipment issue. If Production Events are timestamped against planned shift boundaries rather than actual PLC timestamps, shift 2's output may be recorded as shift 1 production. This introduces errors in both traceability and OEE calculation simultaneously. The fix requires PLC-sourced timestamps as the authoritative source for Production Event records, not operator-entered shift start/end times.
Machine configuration version at time of production: A quality escape is traced to a specific die set that was wearing out of tolerance. The traceability system recorded the machine ID but not the die set ID in use at the time. Without that, the quality team knows the machine but cannot narrow the affected run to the period when the worn die was installed. Production Event records must capture not just machine ID but configuration state: tooling ID, die lot, recipe version, and any setup approval records.
IATF 16949 and ISO 9001 Traceability Requirements
For automotive supplier manufacturers, IATF 16949:2016 clause 8.5.2 requires that the organization control and record unique identification of product throughout production and service, and that traceability is maintained to customer requirements. The specific traceability depth — how far back into the supply chain, and how far forward to end customer — is typically defined in customer-specific requirements (CSRs) from Tier 1 and OEM customers. Some automotive OEM CSRs require traceability to raw material heat number; others require only lot-level traceability to the immediate supplier.
ISO 9001:2015 clause 8.5.2 is less prescriptive: it requires that the organization control identification and traceability "when it is a requirement" — leaving the scope to the organization and any applicable regulations or customer contracts. For facilities working toward ISO 9001 compliance, traceability is a designed system rather than a mandated one, which gives more architectural flexibility but also more risk of gaps.
We are not saying IATF or ISO certification requires a specific software stack. These standards describe what records must exist and what information must be linkable — the data model is the organization's responsibility, and it can be implemented in a dedicated MES, a process intelligence layer, a configured ERP module, or even well-designed spreadsheets for very simple production operations. The critical point is that the data model must be defined before the production run, not reconstructed after a quality event.
Building Traceability from Existing PLC Infrastructure
For brownfield facilities, the most practical approach is to build the lot traceability layer onto existing PLC infrastructure rather than waiting for an MES deployment. Consider a precision castings manufacturer in Kanagawa Prefecture running Omron Sysmac NJ-series controllers on 4 machining cells. The PLC already records cycle counts and fault codes per operation. By adding three data capture points — goods-in lot scan at receiving, work order issue scan at line start, and output serial number print-and-scan at final inspection — a basic traceability chain can be established that links incoming material lots through production runs to shipped units.
This is not a full production genealogy with process parameter history. But it is sufficient for a first-pass recall response: "which shipped units came from this material lot" can be answered within minutes. The Production Event layer with parameter history is a Phase 2 project that extends the depth of traceability rather than establishing it from zero.
The sequencing principle that matters here is: start with the question you need to answer in a recall event, and work backward to define the minimum recording points required. Everything else is enhancement. A lot traceability system that captures material lot and output serial numbers reliably is worth more than one that captures 50 parameters but has material lot gaps on 15% of production runs because the recording step was too burdensome for operators to complete consistently.
Query Design for Recall Response
A final element that is worth designing explicitly: the recall query. Once the data model is in place, someone will need to run a query on a Thursday afternoon. If the query requires a database specialist, it will not happen within 30 minutes. If it is a pre-built report with a material lot ID input field, any quality team member can run it.
Pre-built traceability queries worth having ready: forward trace from material lot to shipped units; reverse trace from serial number to material lots and machine configuration; all production in a date range on a specific machine; all units produced during a specified tooling interval. These cover the most common quality investigation scenarios. The architecture that supports them — a lot genealogy data model with indexed foreign keys across the four entity types described above — is the same architecture that makes ad-hoc queries possible when an unanticipated scenario arises.
Traceability is ultimately an investment in future speed. The work happens upfront, during system design and recording point implementation. The return is measured in hours saved on a Thursday afternoon that nobody planned for.