Software Version History as Liability Evidence

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

A version trail reconstructs the product that actually operated

Software version history helps identify what a product could do when an incident occurred. It can connect a release to configuration, dependencies, changes and manufacturer control. Under Directive (EU) 2024/2853, those records can inform defectiveness and causation without deciding either question by themselves. A list of releases is useful only if it can be connected to the particular product and event being assessed.

The software product liability framework provides the legal context. A version trail is an evidence aid, rather than a compulsory universal repository format under the Directive. Its value depends on provenance, completeness and the link between a release label and deployed behaviour. Investigators should distinguish the historical state established by records from the state merely inferred from present-day inspection.

Link the label to a specific artefact

A version such as 3.2 may identify several platform builds or repackaged releases. Preserve the release identifier and the relevant executable or package, with available integrity information. Record the source, collection date and method. Where a binary is rebuilt from source, explain whether the process can reproduce the originally supplied artefact and what differences remain.

A source-code tag alone does not establish the deployed product. Build options, dependencies and packaging can change behaviour. Keep manifests and build records that connect source, compilation and distribution. If the original artefact cannot be recovered, identify the best available substitute and its limits. Do not silently present a fresh build as the exact executable running during the incident.

Preserve configuration and deployment context

The same release can operate under different feature flags, permissions and service settings. Record those values and their effective times. A staged rollout may activate a feature for only part of a user population. A release published globally may never have reached the affected device. Installation logs and activation acknowledgements are therefore more informative than publication dates alone.

For connected products, include hardware revision, embedded software and relevant external service state. Two devices displaying the same application version may still behave differently. Preserve the records linking the incident product to the rollout group, account or configuration in question. Where remote settings changed, determine when the running process adopted them rather than relying only on the time a stored value was edited.

Build one chronology from several clocks

Record the incident time and the source of that time. Device logs, server logs, support tickets and witness recollections may use different time zones or unsynchronised clocks. Establish offsets where possible and document uncertainty. A precise-looking timestamp should not be presented as exact if the clock could have drifted by several minutes.

Separate the time a change was approved, published, downloaded, installed and activated. These can be materially different. A device might download a release before an incident but restart into it afterward. A chronology that collapses those steps can wrongly attribute the event to code that was not yet running. Preserve failed installations and rollback as distinct events in the same history.

Explain why a change was made

Issue records, approvals and test results can explain a release's purpose. Keep the original record and later revisions where available. A short public change log may simplify the technical issue or omit affected configurations. An internal summary created after the incident can provide context but should be distinguished from contemporaneous testing and decision records.

The release records guide examines the evidence of design, approval and distribution behind a version. Together, the records should support a specific question: what changed, why it mattered and whether that changed behaviour operated during the event. A long list of unrelated commits can obscure that inquiry instead of proving a causal account.

Later improvement does not alone prove earlier defectiveness

Article 7(3) says a product is not defective solely because a better product, including an update or upgrade, was already or subsequently placed on the market or put into service. A later release may address performance or usability without proving an earlier safety defect. A safety-related change still needs connection to the incident conditions and alleged harm.

Compare the affected paths, inputs and protection measures across versions. If a newer release avoids the failure, record other differences in its environment. A replacement dependency or default setting may explain the change rather than the advertised fix. Controlled comparisons should identify those limits, preserve unsuccessful results and avoid operating a potentially unsafe product merely to obtain a dramatic reproduction.

Control history and disclosure need factual support

Article 4 defines manufacturer control, and Article 11(2) limits certain later-arising-defect arguments for specified matters within that control. Version records can show who supplied or authorised a change and whether a manufacturer retained the ability to supply software updates. They should not be used to assume that every product remained under unlimited control forever.

Article 9 provides conditional court-controlled disclosure, not unrestricted public access to source repositories. A focused request might identify the affected build, configuration and safety function. Confidentiality and proportionality remain relevant. Keep lawful access and preservation separate from technical curiosity, and record missing evidence so that the legal review can assess whether a specific request or procedural mechanism is appropriate.

Report what the history establishes and what it cannot

Article 10 starts with proof of defectiveness, damage and causation, subject to specified rebuttable presumptions. Version history can help connect those questions to a product state. It does not itself establish Article 6 covered damage or prove that a changed function caused it. Link the chronology to incident observations, technical tests and the alleged mechanism.

The product evidence record mapper can organise initial record questions without assessing liability. The practical output should identify the release believed to be active, supporting records, confidence limits and unresolved alternatives. Preserve the original files and record any collection or examination that may have altered them. A useful version history makes a historical claim reviewable: another examiner should be able to understand why that state was selected and what evidence could change the conclusion.

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 release identifier and corresponding artefact
Configuration and feature-flag history
Download, installation and activation times
Clock sources and offset assessment

A version trail is an evidence aid. The Directive does not prescribe one universal software repository or logging product.

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.