How to Identify the Relevant Product in a Liability Investigation

EU Directive-level explanationUpdated 16 October 2026By ProductLiability.help editorial desk

Begin with the incident rather than a preferred defendant

Write a factual description of what happened, what was observed and what harm is alleged. Distinguish observations from explanations. A device switching off, a person falling and an alarm appearing on screen are observable events; a claim that defective software caused the fall is an explanation needing evidence. Starting with that distinction helps prevent the product map from silently adopting a disputed theory.

The product definition in Article 4 of Directive (EU) 2024/2853 includes more than physical goods. It also expressly covers software, electricity, raw materials and digital manufacturing files. The investigation should consider relevant categories without adding speculative products merely because they exist nearby. The objective is to identify the supplied items capable of participating in the alleged mechanism and preserve their incident-relevant state.

Record identity at a useful level of detail

For hardware, collect manufacturer, model, serial number, batch and revision where available. For software, record package, release, build and relevant configuration. For raw materials, preserve grade and lot information. These details may come from labels, procurement records, deployment systems or retained samples. State the source of each identifier so later assessment can distinguish verified information from a user's recollection.

A product family name is often insufficient. Two devices with identical branding may contain different hardware or software. Conversely, different brands may use the same underlying component. Keep the evidence that connects the particular incident item to its description. A screenshot from a current sales page may explain the range without establishing the specification of the individual product supplied years earlier.

Draw the relationships between the relevant items

Map which products contain, depend on or communicate with which other items. Article 4's component definition includes intangible items, raw materials and related services as well as tangible parts. The explanation of integrated products shows why the whole device and its components may require separate identities. A single label such as system or platform can obscure these relationships.

For a digitally controlled device, identify local software, remote software or services and any physical sensors or actuators involved. Describe what information travels between them and which action follows. Do not decide every component is defective simply because it participated in the sequence. A map is a framework for testing hypotheses, including the possibility that a sound product responded to an external condition.

Preserve transformation and configuration history

Identify relevant changes between original supply and the incident. These can include repairs, replacement parts, configuration changes, software releases and external integrations. Record who performed or approved each change where known. A later product state may not explain the incident state, so preserve earlier records and note any gaps. Avoid assuming that a modern default setting was enabled on the affected installation.

For automated fabrication, retain the original file and the transformation chain into machine instructions. The digital manufacturing files guide explains why the design source, exported file and production input may differ. Similar care is useful for software packages assembled from dependencies. The relevant identity may be the deployed build and configuration, rather than the most recent source-code revision.

Establish dates that select the legal framework

Record making available, first placement on the Union market and putting into service where relevant. These terms have definitions in Article 4. A consumer purchase date can help but may differ from the product's first market placement. Likewise, an installation date and a software release date describe different events. Preserve documents connecting the event to the particular product rather than relying on a general launch announcement.

The corrected Article 2(1) concerns products placed on the market or put into service after 8 December 2026. Article 21 preserves the earlier Directive within its transitional boundary. Check national implementing law and commencement provisions as part of applying that chronology. An accident after December 2026 does not automatically establish that the new framework governs every product involved.

Keep the defect theory separate from identification

Once the map is sufficiently specific, describe the alleged unsafe characteristic for each candidate product. Article 7 concerns expected or legally required safety in all relevant circumstances. The alleged characteristic might involve design, production, instructions or interaction. Record the evidence supporting the theory and the evidence that would contradict it. Classification and an observed malfunction do not automatically resolve defectiveness.

Article 10 separately addresses proof of defectiveness, damage and causation, including conditions for rebuttable presumptions. Preserve evidence capable of connecting the alleged characteristic to the harm. A service log and a device log may need clock reconciliation before their entries can be linked. Explain uncertainty where records are missing or where emergency intervention changed the item before an expert could inspect it.

Separate losses and preserve the resulting map

Article 6's damage categories include important exclusions for the defective product, specified component-related product damage and exclusively professional property. Identify each affected item and its relationship to the alleged defect. Keep injury evidence and other property damage separate from replacement of the product itself. Update the map when new evidence changes identity or relationships, retaining the earlier version and the reason for the revision.

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.

Incident-specific product map with unresolved questions
Identifiers, versions and market-supply chronology
Preservation log recording repairs, updates and examinations

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.

Source register: corrected scope verified 16 October 2026. Article references identify the legal basis. No qualified legal review or national implementation status is claimed.