Safety cases and evidence chains

What a safety case is for

A safety case exists to answer a specific question for a specific audience: is this system acceptably safe to operate, in this context, for this intended use? It is an argument built from claims, supported by evidence, structured so that a reviewer who was not part of the development can follow the reasoning and check the evidence for themselves. This is a different goal from producing documentation for its own sake, and the distinction matters: a safety case with excellent individual documents but no coherent argument connecting them will not survive review.

The chain that has to hold

• Scope: the system boundary, intended use, operating environment and assumptions the case relies on.
• Hazard and risk identification: what can go wrong, how severe it would be, and how the assessment was performed.
• Safety requirements: what the system must do, or must not do, to control each identified hazard, with rationale linking each requirement to a specific hazard.
• Design and architecture: how the safety requirements are realised, including safety mechanisms, redundancy and diagnostics where relevant.
• Verification and validation: evidence that the design does what the safety requirements demand, under representative conditions.
• Residual risk and assumptions: what remains after mitigation, and the operational conditions the argument depends on holding true.

Each link needs to be independently checkable. A reviewer should be able to start at a hazard, follow it to the requirement written to control it, follow that to the design decision implementing it, and follow that to the specific test or analysis that closed it — without needing a guided tour from the people who built the system. When this chain has to be reconstructed manually during review, it is a strong signal that the underlying engineering process, not just the documentation, has gaps.

Common ways safety cases fail under scrutiny

• Assumptions the case depends on are not stated explicitly, so a reviewer cannot tell what would invalidate the argument.
• Safety requirements are written as design solutions rather than as testable statements of required behaviour, making verification ambiguous.
• Verification evidence exists but cannot be mapped back to the specific requirement it was meant to close.
• The hazard analysis is not updated when the design changes, leaving the case arguing about a system that no longer matches what was built.
• Evidence is scattered across tools with no single index, so completeness cannot be confirmed without manual cross-checking.
• Independence of review or verification is claimed but not actually structured into the process.

Building the evidence chain as you go

The most reliable way to produce a safety case that survives review is to build the traceability chain as the system is developed, rather than reconstructing it afterwards. This means writing safety requirements with their originating hazard referenced from the start, tagging verification activities to the requirement they address at the point of test, and updating the hazard analysis at defined change points rather than only at major milestones. Retrofitting traceability across a completed system is possible but consistently more expensive and more error-prone than maintaining it continuously.

• Establish a single source of truth for hazard-to-evidence traceability before detailed design begins.
• Write safety requirements as verifiable statements, reviewed for testability before they are approved.
• Tag verification results to specific requirements at the time testing is performed, not retrospectively.
• Revisit the hazard analysis at defined change control points, and record what changed and why.
• Document assumptions and operating conditions explicitly, and track them so a later change can be checked against them.
• Plan independent review or assessment with real organisational separation, not merely a different individual on the same team.

What reviewers actually check

In practice, reviewers spend disproportionate time sampling the chain: picking a handful of hazards or requirements at random and following them end to end. A safety case that handles the sampled examples cleanly earns confidence quickly; one that requires extensive explanation for each sample invites a much deeper review. Preparing for this means the traceability chain needs to hold for the whole system, not only for the sections the development team expects to be checked.

Frequently asked questions