Safety case

A safety case is not the collection of documents produced during development; it is the argument that ties them together — the claim that the system is safe, the reasoning that supports the claim, and the evidence that backs the reasoning. Standards such as ISO 26262 and IEC 61508 imply the structure of this argument without always naming it explicitly, while some domains require it as an explicit deliverable.

What a defensible safety case contains

• An explicit statement of scope: the system, its boundaries, and the operating context assumed.
• The hazards considered and how they were identified.
• The claims made about how each hazard is controlled, and the argument connecting claim to evidence.
• The evidence itself: analyses, test results, review records, field data where relevant.
• Residual risk, and the justification for why it is acceptable.

The most common weakness in safety cases is an implicit argument: evidence is present, but the reasoning connecting it to the safety claim is left for the reader to infer. A reviewer should be able to follow the argument without reconstructing it from the underlying documents.

Safety cases also need a defined maintenance trigger — a rule for when a change to the system, its environment or its usage requires the argument to be revisited, rather than assuming it remains valid indefinitely.