Traceability establishes identity before responsibility
Component traceability is the ability to connect a supplied item or material to its origin, processing, integration and later history. In product liability investigations, that connection helps establish which component was present, who supplied it and which records concern it. It does not prove the component was defective. A well-traced part can be unrelated to the harm, while a relevant part may initially have incomplete identifiers.
The component and supply-chain liability framework requires identity alongside safety, causation and actor analysis. Traceability supports these inquiries by preventing evidence about one revision or batch from being applied silently to another. Its value lies in the reliability of the connections, not simply the quantity of numbers recorded. Explain what each identifier represents and how the links between identifiers were established.
Distinguish component, batch and finished-product identifiers
A component part number describes a type or specification, while a serial number may identify an individual item. A batch number usually groups production under particular conditions. A finished-product identifier connects the assembly to a market or service history. These references are complementary. None should be assumed to identify every relevant detail without checking the manufacturer's actual numbering practice.
Raw materials may require a different chain. A bulk batch can be divided, mixed, processed and incorporated into many products. Preserve the transformation records rather than expecting every finished item to carry the original material code. Where identification relies on production dates or consumption estimates, record the assumption and range of uncertainty. A probable batch connection should not be described as an individually verified match.
Build links through procurement and assembly
Start with purchase, delivery, stock and production records that connect the supplied component to the affected product. Check whether internal codes combine equivalent items from different suppliers. A procurement system may record only the preferred supplier, while warehouse records show an emergency substitution. Comparing sources can reveal discrepancies that a single database export would miss.
Assembly records can identify when a part was fitted, but they may describe intended rather than actual consumption. Compare them with available inspection records, markings and physical observations. Preserve conflicting information. The guide to supplier documentation as evidence examines provenance and revision control, which are essential where the traceability chain depends on documents created by several organisations with different recording practices.
Include service replacements and later interventions
A product can contain a different component at the incident than it contained at first sale. Repairs, authorised replacements, user modifications and software updates can alter the relevant configuration. Record the dates, installer or supplier, part revision and approval status of each known intervention. Do not infer that a fitted part was original solely because it matches the product manufacturer's brand.
Article 4 of Directive (EU) 2024/2853 defines manufacturer control through specified conduct, authorisation or consent and software update capabilities. Traceability can identify evidence relevant to that definition, but a service record does not itself decide control. Distinguish approval for a replacement category from approval of the particular revision or configuration. Where the service history is incomplete, state which connections remain unresolved.
Trace digital components at build and runtime
A software component's project name is not enough to establish its incident-time identity. Preserve the version, source, build identifier and configuration where available. A manifest can identify a planned dependency while a lockfile or release artefact establishes what was actually incorporated. Runtime plugins and remotely supplied components can require additional records showing what was loaded or executed.
A software bill of materials is useful when its scope and accuracy are known. It may omit an indirect dependency, describe another release or fail to record a vendor modification. Compare it with build records and the relevant artefact rather than treating it as conclusive. The objective is a reliable account of the installed component and supply route, not the longest possible inventory of project names.
Use traceability to target investigation proportionately
A reliable link can identify the correct supplier specification, test report or change notice. It can also distinguish products potentially affected by a problem from those containing another component. That helps narrow technical testing and relevant evidence requests. However, a shared batch does not prove every item contains the alleged fault, especially where the suspected cause is intermittent or introduced during individual assembly.
Article 9 provides conditional court-controlled disclosure with necessity, proportionality and confidentiality safeguards. A specific request for records linking a named component batch to an affected model is different from a demand for the entire supply database. Article 10's proof rules and rebuttable presumptions remain separate. Traceability gaps should be explained as evidential limitations rather than automatically converted into a finding of defectiveness or liability.
Separate chronology from the applicable legal conclusion
Record component production, supply, finished-product placement and later modification dates distinctly. The corrected Directive scope applies to products placed on the market or put into service after 8 December 2026. An accident date or the presence of a recently replaced part does not alone determine the applicable law. The relevant product history and national rules require separate review.
A completed traceability account should let another reader move from the incident product to the component, supplier and supporting records without unexplained jumps. Mark direct matches, inferred links and missing steps clearly. That makes the evidence useful for investigating defect, causation, control and possible responsible actors while preserving the important distinction between identifying a component and establishing liability for harm.
Records that help the review
Use the following as a practical starting point. Select and preserve records appropriate to the product, incident and applicable procedure.
- Identifier crosswalk from supplier to finished product
- Stock, assembly and service replacement history
- Software build, manifest and runtime component records
Independent educational information at EU Directive level. National implementing law and procedure require separate review.
Primary sources and legal scope
This page explains the EU Directive framework. Check national implementing law, the corrected temporal scope and relevant procedure before applying it to a case.
- Directive (EU) 2024/2853, consolidated text: Articles 2, 4, 8, 9, 10 ↗
- Official Journal corrigendum, 7 May 2026: Article 2(1) ↗
Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.