Traceability data model: 8 fields that really count

Anyone who wants to introduce traceability in production usually stumbles over the same question: What do I even need to record? The answers you get fall into two extremes. Either: 'Everything - date, time, machine, tool, temperature, humidity, user, shift ...' Or: 'Just one number per part. Both answers are wrong.

The first extreme creates data graves: terabytes of production data that nobody can find in the audit and nobody can quickly evaluate in the event of a recall. The second extreme creates gaps: A number exists, but it cannot be linked to the production process, the material receipt or the inspection result.

This article describes the minimum data model for traceability in series production: 8 fields that must be present in every data structure - not because standards require it, but because without them, traceability will not work in an emergency. With specific data types, sample values and the standard mapping for IATF 16949, ISO 9001 and EU MDR.

What a traceability data model must do

Before the 8 fields are described, it must be clear what the data model should achieve. Traceability is not an end in itself. It is the structured answer to four questions that are asked in two situations: during an audit and during a recall.

A data model that can answer these four questions for every product delivered - quickly, completely and unalterably - is a traceability data model suitable for auditing. One that cannot fully answer even one of these questions is not.

The 8 mandatory fields are selected in such a way that each of these four questions is covered by at least two fields. This creates redundancy: even if one piece of evidence is missing or in doubt, there is a second one that answers the same question.

The scheme: 8 mandatory fields at a glance

The following reference table shows the complete minimum data model. All 8 fields are defined as mandatory fields - no data record without all 8. Other fields are useful depending on the industry and process, but are optional.

The 8 fields in detail

Each mandatory field has a specific function in the verification chain. The following cards explain for each field: what it is, what data type it must have, what is missing without this field in the audit or callback case - and what question the auditor asks that this field must answer.

Field 01 - Unit identity

Field 02 - Production order

Field 03 - Production timestamp

Field 04 - Material batch(es)

Field 05 - Test result

Field 06 - Process parameter reference

Field 07 - Proof of delivery

Field 08 - Change identifier (ECR reference)

Common format errors and how to avoid them

The 8 fields are well known - but in practice they are often recorded in formats that are worthless in the event of an audit or recall. The following table shows the most common format errors for each mandatory field.

Standard mapping: Which standard requires which fields

The 8 mandatory fields are not arbitrary - they have been distilled from the requirements of the most relevant standards and regulations in DACH manufacturing. The following mapping shows which fields are explicitly or implicitly required by which standards.

The minimum data model is not what standards require. It is what actually helps in the event of damage - and, remarkably, this is very much in line with what standards require.

-Amadeus Lederle CTE, CSP Intelligence GmbH

Implementation path: Introducing the 8 fields in three phases

The 8 mandatory fields cannot be introduced in a week - but neither can they be introduced in a year. The following implementation path shows which fields should be introduced when and in which order the effort and benefits are optimal.

The common key: Why linking is more important than completeness

There are companies that have all 8 fields in their systems - and yet are not traceable. The reason: the fields exist in different systems without a common key. The inspection result is in the quality software. The material batch is in the ERP. The process parameter is in the MES. And the serial number that would link everything is not consistently maintained in any of these systems.

The common key - the unit identity from field 1 - must be managed as a primary key in all systems. Not as an optional reference field. Not as a free text field that is sometimes filled in. But as a mandatory field, without which no data record can be completed in any system.

The minimal data model implemented natively

PRACTICAL TIP

All 8 mandatory fields native and linked

CSP IPM implements all 8 mandatory fields of the minimum traceability data model natively and linked - with the unit identity (serial number or batch) as a continuous key from material receipt to delivery. No data chaos, no system breaks, no missing links.

• Field 1-8 fully implemented: no manual mapping between systems necessary
• Barcode/QR/RFID scan at every step: unit identity automatically adopted as key
• Unchangeable time stamps: machine-set, audit-proof, GoBD and MDR-compliant
• Process parameter log automatically per serial number: screwdrivers, welding devices, test stations directly connected
• Batch linking: supplier batch → goods receipt → production order → serial number - one click, complete chain
• Immediate retrieval of all 8 fields per unit: complete data record can be exported in the audit in < 60 seconds

→ Arrange a demo

Frequently asked questions

Are 8 fields really enough for IATF 16949

? For traceability as such, yes - IATF 16949, section 8.5.2, requires the ability to trace products along the value chain. The 8 mandatory fields fulfill this requirement. However, IATF 16949 also requires further proof of quality (e.g. initial sample inspection, production control plan, measurement system analysis), which are not part of the traceability data model.

The minimum data model is the traceability core - it does not replace the entire quality management system.

How does the data model differ for serialization vs. batch tracing

? The data model is structurally identical - only field 1 differs in the degree of granulation. For serialization, field 1 is a serial number that identifies exactly one unit. With batch tracking, field 1 is a batch number that identifies a group of units. All other 7 fields work the same for both methods.

The decision between serialization and batch tracking affects field 1 - the underlying data model remains the same.

Does field 4 (material batch) have to record all raw materials or only critical materials?

This depends on the risk class of the product and the applicable standards. For safety-relevant products (automotive, medical technology, aviation), all safety-relevant materials should be recorded - including purchased components. For low-risk classes, a restriction to primary materials and safety-critical components may be sufficient.

As a pragmatic rule: record everything that could lead to a recall in the event of a material defect.

Can field 6 (process parameter reference) be a simple Excel file?

Technically yes - but practically not suitable for auditing. Excel files can be edited manually, are not audit-proof and are not unchangeable. In an audit or liability case, an opponent can argue that the file was subsequently changed. Field 6 must refer to a system-generated, unchangeable log - ideally with a time stamp and digital signature.

CSV exports from an MES/IPM with a corresponding archiving backend are acceptable if immutability is ensured by archiving

. How far back do the 8 fields for older products have to be maintained?

In most cases, subsequent maintenance is not possible - historical production data that has not been recorded cannot be reconstructed. The pragmatic approach: Set a cut-off date from which all 8 fields for new products are fully recorded. For products before the cut-off date: supplement as far as possible from existing sources (test reports, delivery bills, ERP data).

Note the cut-off date in the documentation so that it is clear in the audit when the complete model applies.

What is the difference between field 6 (process parameter reference) and the actual process record?

Field 6 is a pointer, not the record itself. The data record of an individual product contains a reference ID, which is used to find the complete process record in the system. The process record itself can comprise many megabytes (for screwdriving data, welding curves, inline measurement data), but is not part of the compact 8-field data record.

This separation is deliberate: the master data record remains clear and can be loaded quickly, while the raw data can be called up via the reference ID if required.

Why is field 8 (change identifier) a mandatory field - and not an optional field?

Because engineering change records occur regularly in practice - and because quality problems often arise precisely at the transition points. A product that was manufactured the day before the change to a new design version has different properties than one that was manufactured the day after.

Without a change identifier, it is not possible to determine whether the problem lies in the old or new version in the event of an error - and how many products are affected.

How many of these 8 fields are typically already present in existing ERP systems

? In a typical SAP or Dynamics installation, fields 2 (production order), 5 (test result, rudimentary) and 7 (proof of delivery) are often present. Fields 1 (unit identity as continuous key), 3 (machine-set time stamp), 4 (complete batch link), 6 (process parameter reference) and 8 (change identifier) are rarely fully implemented in pure ERP systems. This is not an ERP problem - it is an interface problem: ERP knows the order, but not the line. This is precisely where an integrated MES/IPM is the structural solution.