Safety Case¶
Assurance-argument document — instantiates Failure Mode Anticipation
A structured, evidence-backed argument that a system is acceptably safe to operate in a defined context — stating the safety claim, citing the controls and evidence behind it, and judging the residual risk acceptable, valid only until the context changes.
A Safety Case is not another way to find failures — it is the artifact that argues the system is acceptably safe despite them. Its distinguishing contribution among its siblings is that its product is a reasoned, evidence-backed argument with an explicit acceptance verdict at the end. It states a top-level safety claim about the system's function in a defined operating context, decomposes that claim into sub-claims, attaches evidence — the failure analyses, the controls, the test results — to each, and on that basis argues that the residual risk left after all controls is acceptable, naming who has the authority to accept it. Where the analysis methods produce the failure findings and the design review assigns the fixes, the safety case takes those as inputs and makes the leap the archetype otherwise leaves implicit: therefore this is safe enough to operate, here is the argument, and here is who stands behind it — a claim that holds only for the stated context and only until that context changes.
Example¶
An operator seeking approval to run a fully automated metro line assembles a safety case for the regulator. Its top claim is scoped tightly to a defined operating context — this specific line, at defined headways, with platform-edge doors, within a stated speed profile and obstacle-detection envelope. The claim decomposes into sub-claims: trains maintain safe separation, doors interlock with train presence, obstacles on the track are detected and braked for. Under each, the case marshals the evidence — the hazard analyses, the redundancy in the signaling, the test campaigns — and argues that the residual risk each leg leaves is acceptable, with the accountable safety authority named against the acceptance. Crucially, the case binds its own validity to the context: it registers the assumptions it rests on and defines the triggers — extending the line, tightening headways, a serious in-service incident — that force the whole argument to be reopened rather than presumed still true. Approval hangs not on a document's length but on whether the argued acceptance and its maintenance triggers hold up.
How it works¶
- State the claim in a defined context. The top-level safety claim is scoped to specific operating conditions, so "acceptably safe" has boundaries rather than being a blanket assertion.
- Argue, don't just list. The claim is decomposed into sub-claims and structured as an argument — often in a notation like Goal Structuring Notation[n1] — with evidence attached to each leaf rather than piled in an appendix.
- Judge the residual explicitly. For each leg, the risk left after controls is stated and argued acceptable, with the accepting authority named — the acceptance is a decision on the record, not a silence.
- Bind validity to the context. The assumptions the case rests on are registered, and the triggers that invalidate them are defined, so the argument is a living claim rather than a one-time approval.
Tuning parameters¶
- Argument rigor — free prose versus a structured notation versus formal proof. More structure exposes weak links and unsupported leaps, at rising cost to author and read.
- Context tightness — a narrow operating envelope versus a broad one. A tight context is easier to argue and defend but must be re-argued the moment operation strays outside it.
- Evidence bar — analysis, test, or field-proven evidence behind each leg. A higher bar strengthens the case but is slower and sometimes impossible pre-deployment.
- Acceptance authority — the level at which residual risk is signed off, from a local manager to a regulator. Higher authority carries more weight and more process.
- Maintenance-trigger sensitivity — how readily a context change forces re-argument. Sensitive triggers keep the case honest but demand continual upkeep.
When it helps, and when it misleads¶
Its strength is that it forces the step every other mechanism stops short of: from "we did the analyses and added controls" to "therefore it is acceptably safe, here is the argued reason, and here is who accepts what remains." It makes residual acceptance explicit, owned, context-scoped, and challengeable rather than an unstated assumption buried in a pile of analyses.
Its signature failure mode is confirmation bias: a safety case is usually written to support a conclusion the author already wants, so counter-evidence is under-weighted and the argument becomes a persuasion exercise rather than a test — a well-recognized critique of the form. A second, quieter failure is the sound argument resting on a context assumption that operation silently violates: the case is valid, the world is not. The classic misuse is a thick, polished document that convinces a regulator once and is never revalidated when the line is extended or the operating envelope drifts. The guarding discipline is independent challenge of the argument by someone not invested in its conclusion, explicit context assumptions with live triggers, and treating the case as a living artifact that must be re-argued when its world changes.
How it implements the components¶
function_or_requirement— the top-level safety claim is stated about the system's function in a defined operating context; that scoped claim is the root the whole argument hangs from.residual_risk_decision— the case's conclusion is an argued, authority-backed judgment that the risk remaining after all controls is acceptable for that context, with the accepting party named.review_trigger— it registers the context assumptions the argument rests on and defines the changes — scope extension, incident, drift out of the envelope — that force the case to be reopened.
It does not find the failures or assign the fixes — it cites them: it does not score them (risk_priority, severity_scale), which is Failure Modes and Effects Analysis, and it does not assign owned mitigations (mitigation_action, failure_owner), which is the Design Review; the case argues that what remains is acceptable, it does not produce the underlying analysis or the fixes.
Related¶
- Instantiates: Failure Mode Anticipation — the safety case is where anticipated failure, controls, and residual risk are argued into an accountable claim that the system is safe enough to operate.
- Consumes: Design Review supplies the owned controls the case cites as evidence; Failure Modes and Effects Analysis and Incident Pattern Review supply the failure findings and field evidence the argument rests on.
- Sibling mechanisms: Design Review · Failure Modes and Effects Analysis · Failure Scenario Review · Incident Pattern Review · Fault Tree Analysis · Hazard Analysis · Premortem Workshop · Risk Register
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: Safety Case operates by assembles scoped claims, structured arguments, and supporting evidence into an assurance finding. That concrete deployed or enacted form is Assessment, Review & Assurance under the frozen taxonomy.
Nearest alternative: Representation, Specification & Plan — Although Representation, Specification & Plan can support this mechanism, the frozen evidence makes its operative form the act that assembles scoped claims, structured arguments, and supporting evidence into an assurance finding; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Evidence-backed safety arguments tied to operating context are canonical safety-assurance engineering.
Related originating lineages:
- Law & Governance — Regulatory approval materially requires accountable claims and residual-risk acceptance.
- Systems Thinking & Cybernetics — Systems thinking, feedback control, and cybernetics supplies a parallel or contributing lineage for the mechanism's defining operation: a structured, evidence-backed argument that a system is acceptably safe to operate in a defined context — stating the safety claim, citing the controls and evidence behind it, and….
Review resolution: Both blind reviewers agree that engineering_design is the primary historical origin. Explicit reconciliation of alternate_origin_disagreement starts from reviewer_a's mechanism-specific evidence: Evidence-backed safety arguments tied to operating context are canonical safety-assurance engineering. Reviewer A proposed alternates=law_governance, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false; reviewer B proposed alternates=systems_cybernetics, origin_mode=single_lineage, domain_reach=specialized, and encyclopedia_synthesis=false. The final record retains every independently supported alternate from either review (law_governance, systems_cybernetics) without an arbitrary cap, selects origin_mode=single_lineage to represent the combined lineage evidence, and records domain_reach=specialized and encyclopedia_synthesis=false. Present-day transfer is recorded as reach and is not treated as proof of historical origin.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Goal Structuring Notation (GSN) is a standard graphical notation for safety-case arguments, developed by Tim Kelly, that makes each claim, its supporting sub-claims, and the evidence beneath them explicit — precisely so that a reviewer can see where an argument leans on assumption rather than evidence. ↩