Traceability that survives review: from hazard to accepted evidence

Safety evidence rarely fails because a hazard was missed. It fails because the connection between a hazard, the requirement written to control it, the design decision that implements it and the verification that confirms it lives in four different tools and three different vocabularies.

The five links that must hold

• Scope: the product, its intended use, operating conditions and the roles involved.
• Risk: hazards and cybersecurity risks with severity, likelihood and a named owner.
• Architecture: the requirement and design decision that controls each risk, with rationale.
• Verification: the review, analysis or test that demonstrates control, with acceptance criteria.
• Evidence: the retained record, current at the point of delivery and after change.

Three failure patterns

The first is orphaned mitigation: a control appears in the design with no hazard reference, so nobody can say what happens if it is removed. The second is untestable requirements: a safety requirement phrased as an intention rather than a verifiable property, which turns verification into interpretation. The third is stale evidence: analyses that were accurate at a design freeze and were never revisited after the architecture changed.

The test of a traceable programme is simple: pick one hazard at random and follow it to accepted evidence in under ten minutes.

What to do instead

Keep one authoritative risk register with stable identifiers, and reference those identifiers everywhere else — requirements, design records, test cases, review minutes. Write each requirement so its verification method is obvious from the wording. Record rationale where the decision is made, not in a separate document written afterwards. Review the chain on a cadence tied to design change, not to milestones.

This is unglamorous work, and it is the difference between a safety argument that is explained and one that can simply be read.