What Is a System Safety Case? Building Structured Arguments for Hardware Certification

In regulated industries, it isn’t enough to believe your system is safe. You have to argue it—formally, traceably, and in a form that a competent skeptic can examine and challenge. That argument is called a safety case.

The term gets used loosely. Program managers sometimes treat it as a synonym for a safety plan, a hazard log, or a compliance matrix. It is none of those things, though it draws on all of them. A safety case is a structured, reasoned argument, supported by a body of evidence, that a specific system is acceptably safe to operate in a specific context under specific conditions. Remove any part of that sentence—the structure, the evidence, the context, the acceptable-risk qualifier—and you no longer have a safety case. You have a pile of safety artifacts.

Understanding what a safety case actually is, where it came from, how to build one, and what keeps it honest over a program’s lifetime is increasingly important for any engineering team building hardware that can hurt people.

Origins: UK Defense and the Move Away from Prescriptive Compliance

The modern safety case concept traces directly to the UK Ministry of Defence’s Defence Standard 00-56, first issued in 1991 and significantly revised through the 2000s. The context was military systems: complex, one-of-a-kind platforms where prescriptive checklists could never fully enumerate the failure modes of novel technology. The MoD needed a framework that forced contractors to think through safety rather than just check boxes.

Def Stan 00-56 required that a Safety Case be produced as a living artifact, updated as the design evolved, and structured as an explicit argument from defined safety requirements through hazard analysis to a top-level claim of acceptable safety. The contractor had to defend the argument, not just produce the paperwork.

The Piper Alpha offshore platform disaster (1988) and the Clapham Junction rail crash (1988) created parallel pressure in civil industries. Both events revealed how safety documentation could be voluminous and formally compliant while the underlying argument for safety was hollow. Lord Cullen’s inquiry into Piper Alpha explicitly recommended goal-based rather than prescriptive safety regulation.

The idea spread quickly:

• Nuclear: The UK nuclear safety regulator (then the NII, now ONR) adopted safety case requirements through the 1990s. Nuclear safety cases for plant modifications are among the most demanding in any industry.
• Rail: The UK Railways and Other Guided Transport Systems (Safety) Regulations 2006 and the European Common Safety Method require safety cases for significant changes to railway infrastructure and rolling stock.
• Aviation: While aviation uses different terminology—the EASA/FAA certification basis is structured around safety objectives and means of compliance—the concept of a documented, auditable safety argument is fundamental. DO-178C (software) and DO-254 (programmable hardware) both require artifacts that constitute an implicit safety argument.
• Automotive: ISO 26262 for functional safety and, increasingly, ISO 21448 (SOTIF) require safety cases as part of functional safety assessment for automotive E/E systems. The safety case concept is now embedded in the ISO standard itself.

The common thread across all these domains: a shift from “show me your procedures” to “show me your argument.”

Goal Structuring Notation: A Grammar for Safety Arguments

You can write a safety argument in prose. People have, and it’s a disaster. Natural language arguments for complex systems become circular, ambiguous, and untraceable. Reviewers get lost. Claims get repeated without being supported. Evidence gets cited for the wrong thing.

Goal Structuring Notation (GSN), developed at the University of York in the 1990s and now maintained by the GSN Community Standard, gives engineers a formal visual grammar for safety arguments. It doesn’t replace engineering judgment—it makes the structure of that judgment explicit and reviewable.

GSN uses six core element types:

Goals (G): Claims that must be true. The top-level goal of a safety case is typically the safety claim: “System X is acceptably safe to operate as Y in context Z.” Goals decompose into sub-goals until they reach a level supportable by direct evidence.

Strategies (S): The approach used to break down a goal into sub-goals. A strategy might be “argument by enumeration of hazards” or “argument by architectural independence.” Making the strategy explicit forces the arguer to commit to why they’re decomposing a claim the way they are.

Solutions (Sn): The leaf nodes of the argument—pointers to actual evidence. A solution node references a specific artifact: a test report, a hazard analysis entry, a verified requirement, a simulation result, a field data set.

Contexts (C): Scoping statements that define the boundaries under which a claim holds. A context node attached to a goal might say “in ambient temperatures between -20°C and +55°C” or “with software version 3.4.1 or later.”

Assumptions (A): Explicit statements of things taken as true without direct evidence. Making assumptions explicit is one of GSN’s most valuable features—it forces engineers to surface claims that would otherwise hide inside a strategy.

Justifications (J): Supporting rationale for why a strategy is a valid approach to decomposing a goal.

The result is a directed acyclic graph—a tree of structured reasoning—where every leaf is a pointer to evidence and every internal node is a claim with an explicit decomposition strategy. An assessor can traverse the graph and ask: Is this goal fully decomposed? Is every solution an actual piece of evidence? Are the context nodes honest about the scope? Are the assumptions defensible?

GSN has a close competitor in the Claims-Arguments-Evidence (CAE) notation, which is functionally similar but simpler and more common in some nuclear and rail contexts. Both serve the same purpose: making the logical structure of a safety argument visible.

Evidence Nodes: What Goes Into a Safety Case

A well-formed GSN argument is only as strong as the evidence it references. The solution nodes in a safety case draw from several types of engineering artifacts:

Hazard analysis outputs: HAZOP studies, FMEA/FMECA results, Fault Tree Analysis (FTA), Event Tree Analysis (ETA), and STPA (System-Theoretic Process Analysis) are the primary methods. Each produces a structured catalogue of hazardous conditions and their causes. These become evidence that specific hazards have been identified and addressed.

Requirements: Safety requirements—both derived from hazard analysis and allocated from higher-level standards—must be traceable to the hazards that motivated them and to the design elements and tests that verify them. A safety requirement that exists in isolation, with no upstream hazard analysis and no downstream verification, is evidence of nothing.

Design artifacts: Architecture documents, interface control documents, hardware design descriptions, and software specifications all serve as evidence that the system is designed to meet its safety requirements. For hardware, this includes schematic reviews, derating analyses, and component qualification records.

Verification and validation evidence: Test reports, analysis results, inspection records, simulation outputs, and review minutes. This is often the largest body of evidence in a safety case, and the traceability from test results to the requirements they verify to the hazards those requirements address is where most safety case arguments become fragile.

Field and operational data: For derivative designs or mature systems, historical operational data on failure rates and maintenance records can constitute evidence. This is common in aviation and nuclear contexts.

The challenge isn’t generating these artifacts—most engineering programs produce them anyway. The challenge is linking them into a coherent argument with maintained, accurate traceability. A test report cited as a solution node needs to be the right test for the right requirement addressing the right hazard at the right version of the design. When any of those elements changes, the safety case must be re-examined.

Traceability: What Makes a Safety Case Defensible

The single most common failure mode in safety cases is broken or incomplete traceability. The argument looks complete on a diagram. The evidence exists somewhere. But the links between them—requirement to hazard, test to requirement, design element to requirement, GSN node to artifact—are maintained in spreadsheets, document appendices, or people’s heads.

This creates three specific failure modes:

Stale evidence: A test was run against design version 2.1. The design is now at 3.0. The GSN node still points to the old test report. The argument is now false, but it doesn’t visibly break.

Orphaned requirements: A hazard analysis identified a new failure mode and a new requirement was added. Nobody updated the GSN argument or the test plan. The requirement exists, the hazard exists, but they’re not connected.

Undiscovered gaps: Nobody has explicitly traced from every safety requirement to the evidence that it’s been verified. The gaps are invisible because the traceability structure doesn’t exist to reveal them.

These aren’t hypothetical problems. They are the most common findings in independent safety assessments. The typical response is a manual traceability audit—expensive, time-consuming, and still incomplete.

A defensible safety case requires more than document management. It requires a live traceability model: a structure in which requirements, hazards, design artifacts, and test results are nodes in a graph, and their relationships are first-class data that can be queried, verified, and updated as the design evolves.

How Modern Tools Support Living Safety Cases

Legacy requirements management tools—IBM DOORS, DOORS Next, Polarion, Jama Connect, Codebeamer—all support traceability to varying degrees. They are legitimate, capable tools. DOORS in particular has been the backbone of safety-critical programs in aerospace and defense for decades, and its depth of configuration for complex traceability schemes is real.

The limitation these tools share is architectural. They are built on document or record-based models. Traceability is implemented as links between records, but those links are not the primary organizing principle—documents and modules are. When a safety case requires you to reason about a graph (what claims support this top-level goal? what evidence supports this claim? what happens to the argument when this requirement changes?), document-centric tools force you to reconstruct that graph mentally from a set of tables and link reports.

This is manageable on small programs. On programs with thousands of requirements, hundreds of hazard analysis entries, and complex design hierarchies, it becomes an ongoing maintenance burden that teams underinvest in—which is how safety cases become stale.

Flow Engineering addresses this directly by building traceability as the primary data model rather than a feature layered on top of document management. In Flow Engineering, every requirement, hazard, design element, test result, and verification record is a node in a graph, and the relationships between them are explicit, typed edges. The model is the artifact—not a representation of an artifact stored in a document.

This architecture matters for safety cases in specific, practical ways. A team building a GSN argument in Flow Engineering can query the model: “Show me all safety requirements derived from hazard H-042.” “Show me which requirements have no verification evidence.” “Show me what changed in the design since the last safety assessment.” These aren’t manual trace exercises—they’re graph queries against a maintained model.

Flow Engineering’s AI-assisted capabilities are also relevant here. When a design change is proposed, the system can identify the upstream hazards and safety claims potentially affected, surface the downstream requirements and tests that need re-examination, and flag gaps in the traceability chain. For safety cases—where a design change can invalidate multiple threads of the safety argument simultaneously—this kind of impact analysis is the difference between a living safety case and a document that ages out of accuracy immediately after it’s approved.

Flow Engineering is purpose-built for hardware and systems engineering teams in regulated domains. It doesn’t try to be a full lifecycle management platform for every artifact type. Teams that need deep integration with legacy DOORS vaults or complex ECM workflows may need bridging strategies. But for teams building new programs and wanting a traceability model that actually supports safety case assembly and maintenance, it represents a different architectural choice than the document-centric incumbents.

Practical Starting Points

If you’re starting or restructuring a safety case effort, the order of operations matters:

1. Establish the top-level safety claim first. Define the system, the operating context, and the acceptable risk criterion explicitly. Everything in the safety case argument exists to support this claim. If the claim is vague, the argument will be vague.

2. Choose a notation and stick to it. GSN is the dominant choice for new programs. CAE is simpler and may suffice for smaller systems. Either way, use a tool that renders the notation formally—don’t build the argument in PowerPoint.

3. Map your evidence inventory to your argument structure early. Before the argument is complete, identify what hazard analysis methods will be used, what types of requirements will exist, and what verification methods will be employed. This shapes the solution nodes before the evidence exists, forcing you to plan it.

4. Build traceability as a model, not as a document. Whether you use Flow Engineering, a properly configured instance of another modern tool, or a carefully designed DOORS structure, the traceability relationships need to be machine-queryable. Spreadsheet traceability matrices do not scale and do not stay current.

5. Plan for change from day one. Treat the safety case as a living argument that will be updated with every significant design change. Assign responsibility for safety case maintenance as a named role, not a periodic documentation task.

Honest Assessment

The safety case concept is genuinely powerful. It forces engineering teams to reason explicitly about what they’re claiming, on what basis, and within what limits. It makes gaps visible. It makes assumptions explicit. When it works, it produces a body of evidence and argument that a regulator, an independent assessor, or a future engineering team can examine and trust.

When it fails, it fails quietly. The diagram looks complete. The evidence exists. But the links are wrong, the versions don’t match, and the argument doesn’t actually hold. The tools and practices described here exist specifically to prevent that failure mode—to make the argument not just constructed, but maintained.

Safety cases are ultimately arguments that real people will rely on when deciding whether a system is safe to deploy. That obligation deserves more than document management.