A considered approach to product risk
Clarity starts with the evidence.
A considered approach to product risk. Bring physical products, digital systems and technical records into one clear picture of what needs review.
Find your starting point
Follow the question.
From the product itself to the records that explain what happened, choose the part of the story you need.
Software & digital product risk
Understand the version, dependencies and operating context behind a reported software issue. A label such as current release may conceal important differences between deployments.
Open topic guide02 / Technical reviewProduct failure analysis
Move from a reported symptom to a testable explanation. A product-risk review should define the affected item, operating circumstances and proposed failure mechanism.
Open topic guide03 / Product relationshipsResponsibility & supplier mapping
Give each business a clear place in the product record. A factual role map helps a review follow development, supply, integration and changes without prejudging legal responsibility.
Open topic guide04 / Records & proofEvidence organisation
A useful evidence set explains where a record came from, what it concerns and which question it can help answer. Volume alone does not create clarity.
Open topic guide05 / ConsequenceIncident consequences & loss records
Record the consequences of an incident separately from the explanation of its cause. Clear descriptions help specialists assess the relevant technical, operational and legal questions.
Open topic guide06 / International reviewJurisdictions & market context
A product can reach several markets under different legal regimes. Record the market context before applying a standard or legal assumption to the whole product portfolio.
Open topic guideAn illustrative evidence trail
One product.
Several questions.
A connected device, a changed release, an incident. Follow the records through three stages of an investigation.
Establish the product state
Indoor air-quality controller
Identify the hardware, embedded software and digital services. Connect each component to its supplier and the version present at the incident.
- PRODUCT RECORDModel · batch · market date
- COMPONENT RECORDSupplier · revision · integration
- SOFTWARE RECORDRelease · configuration · control
Reconstruct the change
A release alters device behaviour.
Preserve the before and after versions, the approval and the rollout. Separate a reported symptom from a demonstrated safety defect.
- BEFOREVersion 2.3 · baseline tests
- CHANGEVersion 2.4 · signed approval
- AFTERIncident-time logs · configuration
Connect records to questions
What can the evidence establish?
Build the failure mechanism and investigate alternative explanations. Keep the alleged defect, harm and causal connection distinct.
- DEFECTSafety assessment · testing
- DAMAGEContemporaneous harm records
- CAUSATIONMechanism · alternatives · limitations
Look a little closer
The details make a difference.
Control & change decisions
Know who can approve, supply and apply changes. Control records help explain how a product’s functions evolved and which decisions require closer review.
Assumptions, inferences & uncertainty
A careful review distinguishes a direct observation from an inference and an unanswered question. The basis of each conclusion should remain available for inspection.
Version & configuration history
An incident-time version record connects the release, dependencies and configuration actually in use. It is a practical foundation for reproducing behaviour and understanding changes.
Clear sources. Clear limits.
A resource you can inspect.
Read the source references and the limits of each explanation. Illustrative examples are labelled throughout.