Software Release Records and Product Liability

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

Release records explain the supplied software and its approval

Software release records can connect technical changes, safety reasoning and distribution to the product involved in an incident. They are useful under Directive (EU) 2024/2853 because defectiveness, manufacturer control and causation can depend on the particular software state. A release package appearing in an archive does not alone prove that the affected product received it or that it was unsafe.

The software product liability overview explains the legal conditions. Release records concern how a particular artefact was defined, reviewed and supplied. They complement runtime and incident evidence rather than replace it. A mature investigation uses them to answer specific questions about the alleged failure, while recognising that a documented approval process is not itself proof that the resulting product provided all required safety.

Preserve the release identity and its contents

Retain the executable or package, release identifier, platform, dependency manifest and relevant build configuration. Record the source and integrity of the preserved artefact. If several packages share the same marketing version, identify the one intended for the affected product. An archive containing only a source snapshot may leave compilation and packaging questions unresolved.

Compare the preserved contents with the distribution records. A package can be approved internally but never released, replaced before distribution or withdrawn after limited rollout. Keep those distinctions visible. Where the original supplied package is missing, identify the available substitutes and their limits. A later rebuilt package should not be represented as the original artefact without supporting evidence of equivalence.

Connect safety reasoning to the actual change

A release may contain a new feature, a defect correction and several unrelated maintenance changes. Identify the parts relevant to the alleged unsafe mechanism. Keep risk assessments, design decisions and review comments where available. A general checklist stating approved may not explain how a particular safety interaction was assessed or which assumptions underpinned the decision.

Article 7 assesses the product's safety in all relevant circumstances, including technical characteristics, instructions, foreseeable use and interactions. Release decisions can illuminate those circumstances without replacing the legal test. A team following its internal procedure may still have supplied an unsafe product. Conversely, a missing administrative record is not by itself proof of a defect that caused the reported damage.

Evaluate tests against the disputed operating conditions

Record what was tested, on which hardware and software combinations, with which configuration and inputs. A passing result is evidence of that test under those conditions. It does not establish that every foreseeable combination was safe. A failing development test also needs context: it may concern a discarded build or a condition later corrected before supply.

Preserve the connection between test results and the release artefact. If dependencies changed after testing, explain whether relevant testing was repeated and what evidence supports the decision. For an intermittent problem, retain negative results and attempts that did not reproduce the event. Selective presentation of only one dramatic result can conceal the limits of the technical account.

Separate approval, distribution and activation

An approval timestamp identifies a decision, not deployment. A distribution record can identify a rollout group, but the device may have remained offline or rejected installation. Record delivery, download, installation and activation where available. Failed attempts and rollback can be particularly important when the alleged event occurs near a release boundary.

The version history guide explains how to place those steps in one incident chronology. For release records, keep the responsible actor and authorisation for each step. Article 4's manufacturer-control definition makes specified actions, consent and update-supply capability relevant. An outsourced distributor does not automatically mean the software change occurred beyond manufacturer control, and technical access alone does not settle the legal relationship.

Read change logs and support notices carefully

A public note may describe a correction in simplified language and omit platform limitations. Match it to the underlying issue, affected builds and actual trigger conditions. A report titled fixed overheating might refer to a protective warning, a visual display or a control change. Its title cannot establish the entire causal explanation of an injury or property event.

Article 7(3) also prevents defectiveness being established solely because a better product or update exists. Later records can provide evidence of a mechanism, but their meaning depends on the earlier state and incident facts. Preserve publication dates and revisions so a later explanation is not mistaken for knowledge documented before supply. Distinguish contemporaneous findings from a retrospective account.

Keep harm and actor questions in view

Release evidence often concerns what changed, while Article 6 concerns what damage is covered. A technically serious release error causing only business downtime does not automatically satisfy that damage requirement. Personal injury, eligible property damage and non-professional data corruption require their own records. Keep a technical cause analysis connected to each specific alleged loss.

Likewise, identify who developed, supplied, branded or integrated the relevant product under Articles 4 and 8. A name in an approval field may identify an employee acting for a business, not a separate manufacturer. Preserve organisational context and contractual roles without using internal signatures as a shortcut to legal responsibility. Product, component and finished-product relationships need explicit examination.

Use records proportionately and acknowledge gaps

Article 9 provides conditional court-controlled disclosure with necessity, proportionality and confidentiality safeguards. A focused request can name the affected release, disputed function and relevant test or approval category. It does not follow that every source-code repository, employee message or unrelated customer record must be disclosed. Explain why the requested material could answer an actual issue.

Article 10 starts from proof of defectiveness, damage and causation, subject to specified rebuttable presumptions. Missing release records may create an evidential gap, but not every missing document independently establishes those elements. State what was searched, what survives and which conclusions remain uncertain. The practical result should be a reviewable account connecting a supplied release and its decisions to the incident, without treating documentation volume as a measure of legal liability.

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.

Release package and build manifest
Change-specific safety assessment and tests
Approval and distribution records
Installation and activation evidence

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.