The topic library
A connected view
of product responsibility.
Browse the questions, evidence and relationships that shape a product-risk investigation.
Showing 106 to 120 of 142 topic guides
Firmware Product Liability: Unsafe Control and Evidence
A firmware investigation follows the deployed code, calibration, boot behaviour and hardware response. A visible version label alone cannot establish the incident-time state or explain an alleged unsafe control failure.
Read guide107 / Software product liabilityMobile App Product Liability: Unsafe Functions and Proof
A mobile app investigation connects its function, permissions, device state and remote configuration to the alleged harm. Publisher, developer, platform and connected-device roles need separate examination.
Read guide108 / Software product liabilityOperating System Product Liability: Failure Paths and Evidence
Operating system liability requires an account of the affected build, drivers, settings and failure path. A crash or restart does not by itself identify a safety defect, covered harm or the responsible actor.
Read guide109 / Software product liabilitySoftware Bugs vs Legally Defective Software
A software bug can support a product liability investigation, but technical error, legal safety defectiveness and covered damage are separate questions. The alleged mechanism must connect the affected release to the harm.
Read guide110 / Software product liabilitySoftware Configuration and Product Liability
Settings, feature flags, permissions and calibration can change product behaviour without changing its code. Preserve the applied state, its origin and its causal effect rather than relying only on default values.
Read guide111 / Software product liabilitySoftware Dependencies and Liability: Reconstructing the Failure Chain
Dependency evidence reconstructs which components were present and executed, how their behaviour propagated and whether an interaction affected safety. A package entry or advisory alone does not establish liability.
Read guide112 / Software product liabilitySoftware Maintenance and Product Liability
Maintenance records can explain changed code, configuration, compatibility and continuing manufacturer control. A support policy or service ticket does not alone establish an update obligation, a safety defect or causation.
Read guide113 / Software product liabilitySoftware Product Liability Investigation Checklist
A software investigation identifies the product, date, unsafe mechanism, harm, deployed state and relevant actors. Preserve competing explanations and focused evidence gaps before drawing a legal conclusion.
Read guide114 / Software product liabilitySoftware Release Records and Product Liability
Release records connect an artefact to technical changes, safety decisions, testing and distribution. They help test a causal account without making internal approval or a later improvement conclusive evidence of safety or defectiveness.
Read guide115 / Software product liabilityStandalone Software and Product Liability
Separately supplied software can fall within the new EU product liability framework. Identify the application, its safety function, supply circumstances, deployed state and actual harm before assessing responsibility.
Read guide116 / Software product liabilityThird-Party Libraries and Product Liability: Who Supplied the Defective Component?
A defective third-party library can raise component and finished-product liability questions. Identify the supplied artefact, commercial context, integration control and statutory conditions before allocating responsibility or recourse.
Read guide117 / SaaS, cloud software and related servicesAPI Failures and Product Liability
API errors require an account of the supplied software or service, actual exchange, receiving product response and harm. An interface failure alone does not establish liability.
Read guide118 / SaaS, cloud software and related servicesCan SaaS and Cloud-Delivered Software Be Products for Product Liability?
SaaS, cloud execution and network delivery can all involve a software product. Separate that classification from related services, safety defects, qualifying damage and responsibility.
Read guide119 / SaaS, cloud software and related servicesCloud Configuration and Product Defects
Cloud settings can change safety without a new software build. Establish the effective configuration, authorised changes, safety mechanism and resulting harm using incident-time evidence.
Read guide120 / SaaS, cloud software and related servicesEvidence for Cloud-Dependent Product Failures
Reconstruct the incident-time device, deployment, settings and service sequence. Preserve provenance and harm evidence while respecting disclosure limits, confidentiality and uncertainty.
Read guideNo topics match. Try a broader term or choose all areas.