What Is a Safety Case and How Is It Used in Regulated Industries

A safety case is a structured argument, supported by evidence, that a system is acceptably safe for its intended use in a specific operating context. That definition contains three load-bearing words: structured, argument, and evidence. Remove any one of them and what you have left is not a safety case—it is either an unsubstantiated claim, an informal narrative, or a pile of test reports with no connecting logic.

The concept emerged from the UK offshore oil and gas sector after the 1988 Piper Alpha disaster. The Cullen Inquiry concluded that prescriptive rule-following was insufficient; operators needed to demonstrate that they understood the risks of their specific system and had taken appropriate measures for their specific context. That principle—context-specific, argued, evidenced—spread to nuclear, rail, defense, medical devices, and, more recently, autonomous systems.

Understanding what a safety case is, how it is formally structured, and where it sits inside real certification frameworks is foundational knowledge for any engineer working on a safety-critical system.

The Core Definition: Argument Plus Evidence

The most widely cited definition comes from the UK Ministry of Defence’s Defence Standard 00-56: a safety case is a structured argument, supported by a body of evidence, that provides a compelling, comprehensible, and valid case that a system is safe for a given application in a given operating environment.

Four qualities matter here:

Structured. The argument must be decomposable. A top-level safety claim (“the system is acceptably safe”) must break down into sub-claims that can each be evaluated independently. If you cannot decompose the argument, you cannot assess it—and neither can a regulator.

Argument. Logic connects claims to evidence. You are not simply listing test results. You are asserting that these results, given these assumptions, under these operating conditions, support this safety claim. The argument makes the reasoning explicit.

Evidence. Every terminal claim in the argument must be grounded in something observable: a test result, a formal proof, a hazard analysis, an operational record, a design document, an inspection report. Evidence without argument is a data dump. Argument without evidence is speculation.

Context-specific. A safety case for a train control system on a high-speed mainline is not the same as a safety case for the same software running on a heritage railway. The operating environment is part of the argument, and changing the environment changes the case.

Goal Structuring Notation (GSN)

GSN is the most widely used graphical notation for representing safety case structure. Developed at the University of York in the 1990s and standardized by the Safety Critical Systems Club, GSN uses six primary elements:

  • Goal (G): A claim about the system or its properties. Example: G1: The braking system shall not cause hazardous deceleration under normal operating conditions.
  • Strategy (S): The approach used to argue for a goal. Example: S1: Argument over identified failure modes.
  • Solution (Sn): A reference to a piece of evidence—a test report, analysis, inspection record. Terminal nodes only.
  • Context (C): Conditions and constraints that bound the argument. Example: C1: Operating environment is mainline rail, max 200 km/h.
  • Assumption (A): An explicit statement of something taken to be true that is not argued within this case.
  • Justification (J): A rationale for a strategic choice.

GSN diagrams read from top to bottom. A top-level goal decomposes through strategies into sub-goals, and those sub-goals eventually reach solutions. The notation makes the entire logical chain visible in a single diagram, which is why regulators find it useful—they can trace any piece of evidence back to the top-level claim without reading thousands of pages of prose.

A well-constructed GSN diagram also makes gaps visible. If a sub-goal has no attached solution or undeveloped marker (“TBD”), that is an open claim in the safety case. You cannot close a safety case with open claims.

Claims-Arguments-Evidence (CAE)

CAE is the conceptual pattern that underlies GSN and several other safety case formats. It predates GSN as a formal notation and is used in contexts where graphical tooling is not available or where a more narrative presentation is required.

The CAE structure is:

  • Claim: What you are asserting. The system tolerates a single actuator failure without loss of control.
  • Argument: Why the claim is true. Single-fault tolerance was demonstrated through FMEA and confirmed by hardware-in-the-loop testing under simulated actuator failures.
  • Evidence: The artifacts that support the argument. FMEA report FME-2025-007, HIL test results HIL-TF-031 through HIL-TF-048, reviewed and signed off by the independent safety assessor on 2025-11-14.

CAE is recursive. Each piece of evidence can itself be a claim that requires its own argument and evidence. FMEA-2025-007 is a credible piece of evidence only if you can argue that the FMEA was conducted correctly, which requires evidence of who conducted it, what method was used, and what review process was applied.

This recursive structure is why safety cases become large and why managing them manually—in Word documents or spreadsheets—becomes untenable at system scale.

How Safety Cases Are Used in Regulated Industries

Rail: EN 50126 and CENELEC Suite

The EN 50126 standard (RAMS: Reliability, Availability, Maintainability, Safety) governs railway applications across the EU and many other jurisdictions. Together with EN 50128 (software) and EN 50129 (hardware/system safety), it defines a lifecycle in which a safety case is the formal output that justifies a system’s safety integrity level (SIL) and authorizes it for service.

EN 50129 explicitly requires a safety case as the document that “presents the evidence that a railway system complies with the specified safety requirements.” It must include a system safety argument, a hazard log with closure evidence, and a demonstration that the SIL requirements have been met for each safety function.

The independent safety assessor (ISA) role in the CENELEC framework is essentially a reviewer of the safety case. If the ISA cannot follow the argument or finds evidence gaps, the system does not get certified.

Nuclear: Multiple Frameworks, Same Principle

Nuclear regulation varies by jurisdiction but the safety case concept is universal. The UK’s Office for Nuclear Regulation requires a safety case for any nuclear facility, covering design basis, beyond design basis, and operational safety. The IAEA Safety Requirements documents embed equivalent expectations globally.

Nuclear safety cases are notable for their treatment of uncertainty. Because some failure modes cannot be tested at scale, nuclear safety cases rely heavily on formal analysis, conservative assumptions, and defense-in-depth arguments. The arguments are often probabilistic, citing fault tree analysis and probabilistic risk assessment (PRA) results as evidence—which places heavy demands on the traceability of modeling assumptions to design requirements.

Defense: Def Stan 00-056 and DO-178C

UK defense programs operate under Defence Standard 00-056, which introduced the term “safety case” to mainstream engineering practice. It requires a safety case for every acquisition program and defines a through-life safety management framework in which the safety case evolves from concept through disposal.

Airborne systems under US jurisdiction follow DO-178C (software) and ARP 4754A (systems), which do not use the term “safety case” explicitly but require equivalent artifacts: development assurance plans, verification and validation records, and traceability from requirements to test evidence at each Design Assurance Level (DAL). The logical structure is CAE-compatible even without the label.

Autonomous Systems: Emerging Frameworks

Autonomous and AI-enabled systems are the frontier for safety case methodology. ISO 26262 covers automotive functional safety through ASIL levels; ISO 21448 (SOTIF) addresses insufficiency of specification—the case where the system works as designed but the design is not safe for the operational domain.

SOTIF in particular forces safety cases to address the unknown: operating scenarios that were not anticipated in the hazard analysis. Constructing a credible SOTIF safety case requires argumentation about the completeness of operational design domain (ODD) coverage, which in turn requires traceability from ODD definitions to verification scenarios to test evidence.

Aviation autonomous systems face similar challenges. The FAA’s emerging framework for Urban Air Mobility (UAM) and the EASA concept of operations for unmanned aircraft both anticipate safety case submissions as part of type certification. The argument-and-evidence structure has not changed; the difficulty is that the evidence base for novel failure modes is thin.

The Evidence Layer: Where Safety Cases Break Down

Every safety case problem ultimately reduces to the same failure mode: evidence that cannot be located, traced, or trusted.

An assessor reviewing a safety case for a rail signaling system does not take assertions on faith. They want to see the hazard identified in the hazard log, the requirement that mitigates it, the design element that implements the requirement, the test case that verifies the implementation, and the test record that shows the test passed. That chain—hazard to requirement to design to test to result—must be unbroken and retrievable on demand.

In practice, these chains are maintained in requirements management tools, and the quality of those tools determines whether the safety case evidence layer is credible or fragile.

Document-based tools—Word, Excel, even legacy systems like IBM DOORS in its classic form—store requirements and evidence in artifacts that must be manually linked and manually updated. When a requirement changes, traceability links do not update automatically. When a test is re-executed, the old result may still appear in the safety case document unless someone remembers to update it. The safety case appears complete because the documents are complete, but the evidence is stale.

How Modern Requirements Traceability Platforms Support Safety Cases

Tools designed around graph-based traceability models change the structural relationship between the safety case and its evidence base.

Flow Engineering, built specifically for hardware and systems engineering teams, represents requirements, design elements, verification records, and hazard log entries as nodes in a connected graph rather than rows in a document. Every safety claim in a GSN diagram can reference a node in that graph, and the graph maintains live bidirectional traceability from hazard to requirement to verification to test result.

When an engineer updates a requirement because a design change was needed, the graph immediately surfaces all downstream verification records that are now out-of-date—because the graph knows the topology of the evidence chain, not just the content of individual documents. For a safety case, this means that coverage gaps surface as soon as they are created, not six months later during an independent assessment.

Flow Engineering also maintains a structured change history at the requirement level, which matters for regulatory submissions. Assessors routinely ask: “What changed between revision 3 and revision 4 of this requirement, and what was re-verified?” A graph-based platform answers that question directly. A document-based platform requires someone to have remembered to track it manually.

The AI-native layer in Flow Engineering—which can analyze requirement quality, flag ambiguity, and identify missing traceability links—is directly applicable to safety case development because ambiguous requirements are a documented cause of safety argument failures. A requirement like the system shall respond quickly cannot support a safety argument. The tool flags it before it enters the evidence base.

This does not mean Flow Engineering replaces a safety case. The safety case is an argument structure—a GSN diagram, a CAE breakdown, an assessor-reviewed narrative. What a traceability platform provides is the evidence layer that makes each terminal node in that argument defensible. The argument is only as strong as the evidence it points to.

Practical Starting Points

If you are building a safety case for the first time, or inheriting one that needs to be made credible for an upcoming assessment:

Start with the argument before you audit the evidence. Build the GSN or CAE structure top-down. This identifies which claims need evidence before you start cataloguing what evidence you have. Many safety cases fail because evidence was collected without a clear argument to attach it to.

Close every open claim or explicitly defer it. Undeveloped goals in a GSN diagram must be tracked and owned. A safety case with unresolved open claims is not a completed safety case, regardless of how many documents back it up.

Trace requirements to hazards, not just to tests. Verification coverage tells you that requirements were tested. Hazard-to-requirement traceability tells you that hazards are mitigated. Both chains must be complete.

Version the evidence, not just the document. When a test report is superseded, the safety case must reference the correct version. This is where document-based approaches consistently fail and where a graph-based requirements platform provides structural advantage.

Treat the safety case as a living artifact. A safety case written for initial certification and never updated is not a safety case for the system in service—it is a historical record. In rail and nuclear contexts especially, the through-life safety case must reflect the system as it currently exists.

A credible safety case is not a compliance exercise. It is the answer to a direct question: can you demonstrate, to someone who will probe every assumption, that this system is safe enough to operate in this context? The answer requires a clear argument, retrievable evidence, and the tools to maintain both through a system’s operational life.