What Is a System Safety Case?

A safety case is a structured, evidence-based argument that a system is acceptably safe for a specific use in a specific context. Every word in that definition carries weight.

Structured means the argument has explicit logical form — claims, sub-claims, and the evidence that grounds them — not prose paragraphs that gesture at confidence. Evidence-based means the argument is falsifiable; someone reading it can identify exactly what would need to be wrong for the conclusion to fail. Specific use in a specific context means a safety case for a military UAV operating over unpopulated terrain is not the same safety case as one for the same airframe operating over a city. The context is part of the argument.

Safety cases emerged from UK defense procurement in the 1990s, entered civil aviation through EASA certification frameworks, and are now appearing in autonomous vehicle standards and medical device regulations. The concept travels well because it solves a genuine problem: how do you communicate, to a regulator or a customer, not just that you followed a process, but that you actually believe your system is safe — and why?

Core Concept 1: The Structure of a Safety Case Argument

Goal Structuring Notation (GSN)

GSN, developed at the University of York and now standardized as GSN Community Standard v3, represents a safety case as a directed graph. The key node types are:

Goals — the claims being made. “The aircraft autopilot system is acceptably safe for IFR operations in Class A airspace” is a goal. Goals are falsifiable propositions, not aspirations.

Strategies — the approach used to break a goal into sub-goals. “Argument over identified hazard classes” is a strategy. Strategies make the decomposition logic explicit, which is where most informal arguments hide unsupported leaps.

Solutions — the evidence artifacts that ground a claim. A solution might be a test report, a formal verification result, a FMEA worksheet, or field reliability data. Solutions terminate branches of the argument tree.

Context — the assumptions and operational envelope within which the argument holds. Context nodes are not decorative; they are load-bearing. If the context changes, the argument may no longer hold.

Assumptions and Justifications — explicit statements of what is taken as given, and why a particular decomposition is valid. Making these explicit lets reviewers challenge them directly rather than discovering them embedded in prose.

A complete GSN argument looks like a tree rooted at the top-level safety goal, branching through strategies and sub-goals until every leaf is grounded in a solution. The structure makes gaps visible: an undeveloped goal (marked with a diamond in standard notation) is an open claim with no supporting argument, and it stands out immediately in a visual review.

Claims-Arguments-Evidence (CAE)

CAE, associated with the Adelard ASCE tool and widely used in UK nuclear and rail sectors, uses a simpler three-element structure: a claim at the top, an argument that explains the inferential link, and evidence at the bottom. In practice, claims decompose into sub-claims, producing the same tree structure as GSN, but the notation is less graphically elaborate.

CAE is often preferred when the primary deliverable is a written safety case document rather than a maintained model, and when reviewers are less familiar with formal notations. GSN is generally preferred when the safety case is managed as a living model and when tooling support for traceability is required.

The practical difference between GSN and CAE matters less than it is sometimes made to appear. Both force the same intellectual discipline: state your claim, state how you are arguing for it, and show the evidence. The discipline is the point.

What Constitutes Adequate Evidence

Evidence in a safety case is not simply “we tested it.” Adequate evidence has three properties:

Relevance — the evidence must address the specific claim. A test conducted under conditions different from the operational context may not be relevant to a claim about that context, even if the test results look good.

Sufficiency — the evidence must be strong enough to support the confidence level claimed. A single successful test is rarely sufficient for a high-consequence claim. Independence of evidence sources matters: two pieces of evidence derived from the same underlying analysis are worth less than two independent analyses.

Completeness — the evidence must cover the full scope of the claim. A hazard analysis that covers nominal operation but not reasonably foreseeable misuse does not support a claim about acceptable safety in use.

Regulators and independent safety assessors evaluate these three properties. Teams that produce large volumes of documentation but cannot articulate which evidence supports which claim — or why — typically fail assessments not on the quality of their engineering but on the structure of their argument.

Core Concept 2: Where Safety Cases Are Required

UK Defense: Def Stan 00-56

Defence Standard 00-56, Safety Management Requirements for Defence Systems, is the foundational UK defense safety standard. It requires a Safety Case to be produced and maintained throughout the system lifecycle, from concept through disposal. The standard explicitly defines the safety case as a “documented body of evidence that provides a convincing and valid argument that a system is adequately safe for a given application in a given operating environment.”

Def Stan 00-56 requires the safety case to be updated whenever the design, operational context, or evidence base changes. The standard is explicit that a safety case is not a one-time deliverable; it is a living document that must be maintained. Failure to update the safety case after a design change is itself a safety management failure, independent of whether the change introduced any new hazard.

Civil Aviation: EASA CS-23 and CS-25

EASA Certification Specifications CS-23 (normal-category aircraft) and CS-25 (large aircraft) do not use the term “safety case” in the same explicit way as UK defense standards, but the substance is identical. AMC 25.1309 — the Acceptable Means of Compliance for CS-25 system safety requirements — requires a structured argument linking failure modes, severity classifications, and the design and verification evidence that demonstrates compliance with probability targets.

The safety argument for a CS-25 aircraft must show that catastrophic failure conditions have a probability of occurrence less than 10⁻⁹ per flight hour. That is a quantitative claim, and the evidence must support a quantitative argument. The Functional Hazard Assessment, System Safety Assessment, and Fault Tree Analysis are the primary evidence artifacts, and they must be structurally linked to the claim — not just filed in the same document package.

Autonomous Vehicles: Emerging Frameworks

ISO 26262 (functional safety for road vehicles) and ISO 21448 (SOTIF — Safety Of The Intended Functionality) together establish a safety case obligation for automotive systems, though neither uses the term “safety case” as prominently as Def Stan 00-56. The emerging UN Regulation 157 on Automated Lane Keeping Systems explicitly requires a safety case for Type Approval.

In the UK, the Automated Vehicles Act 2024 creates a formal authorization framework for self-driving vehicles that will require safety case submissions to the Automated Vehicles Safety Framework administrator. The US NHTSA AV guidance documents, while not yet regulatory, point in the same direction.

The evidentiary challenge in autonomous systems is significant: claims about the safety of perception and decision-making systems under distribution shift cannot be fully grounded in pre-deployment testing. Safety cases for AV systems must explicitly address the limits of their evidence and the monitoring and intervention mechanisms that compensate for those limits. Arguments that do not acknowledge these gaps are not credible to technically sophisticated reviewers.

Core Concept 3: The Lifecycle of a Safety Case

A safety case is created at system concept, not after development is complete. The initial safety case contains the top-level safety goals, the hazard log, and the preliminary argument structure — with many undeveloped goals because the design and evidence do not yet exist. As design proceeds, the argument is progressively elaborated and solutions replace undeveloped nodes.

The lifecycle problem is change management. Every design change that affects a hazard or its mitigations must trigger a structured review of the safety case: which claims does this change affect? Which evidence is now stale? Which context nodes are no longer valid?

This is not a bureaucratic exercise. A modification to a software component that changes the failure mode of a mitigation function invalidates every claim that was supported by evidence about the original component behavior. If those claims are not identified and re-evaluated, the safety case continues to assert things that are no longer true — and the gap may not be visible until an accident investigation.

The practical implication is that a safety case managed as a Word document or a PDF package is nearly impossible to maintain correctly. The links between claims and evidence exist only in the author’s memory, not in the artifact itself. When the author leaves the program — or when the program continues for five years through multiple design iterations — those links are lost.

How Modern Tools Support Safety Case Development

The Traceability Problem

The hardest operational problem in safety case management is maintaining live traceability between safety claims, the requirements that implement them, and the test evidence that verifies them. In practice, this means knowing — at any point in the program — that a given safety goal is supported by specific requirements, that those requirements are allocated to specific design elements, and that specific test results demonstrate that the requirements are met.

When any link in that chain breaks, the safety case has a gap. The gap may be real (the evidence genuinely does not exist) or nominal (the evidence exists but the traceability record has not been updated). Both are problems: real gaps are engineering problems, nominal gaps are program management problems. Legacy tools that manage requirements and evidence in separate systems — or in spreadsheets — produce nominal gaps constantly, because updating the traceability record is manual, tedious, and low-status work.

Flow Engineering’s Approach

Flow Engineering addresses this problem through a graph-based model of the entire requirements and evidence landscape. Rather than storing requirements in rows and traceability in a separate RTM spreadsheet, Flow Engineering represents every requirement, every design element, every test case, and every evidence artifact as a node in a connected graph, with typed relationships between them.

For safety case development, this architecture means that a safety claim is a node with explicit, machine-readable links to the requirements that implement it and the evidence that supports it. When a design change is made, the affected nodes are immediately visible — not through a manual search of a document, but through a graph traversal. The question “what claims are affected by this change to Requirement 4.3.7?” has a concrete, automated answer.

Flow Engineering’s AI-assisted features support safety case work specifically in two areas. First, during requirements elaboration, the tool can identify requirements that bear on a safety goal but have not been linked to the safety case argument — surfacing potential gaps before they become audit findings. Second, during change impact analysis, the tool can trace the downstream implications of a proposed change through the requirements model and flag the safety case nodes that require re-evaluation.

It is worth being specific about what Flow Engineering does not do: it does not generate safety arguments, perform hazard analyses, or assess the adequacy of evidence. Those are engineering judgments that require domain expertise. What it does is make the structure of the argument and its evidence dependencies visible and maintainable, which is the precondition for those judgments being made correctly.

Flow Engineering’s focus is on requirements and traceability for hardware and systems engineering teams. If your primary need is a dedicated GSN modeling environment with formal argument checking, tools like Astah GSN or AdvoCATE may complement it. But for teams whose safety case work is embedded in a larger systems engineering workflow — which describes most programs — the ability to manage safety traceability in the same environment as system requirements and verification evidence is a significant practical advantage.

Practical Starting Points

If you are initiating a safety case on a new program, four steps establish the foundation:

1. Define the top-level safety goal in operational terms. Not “the system is safe” but “the system is acceptably safe for [specific mission] in [specific operational context] when operated and maintained in accordance with [specific conditions].” The specificity is not bureaucratic precision; it defines the scope of the argument you need to make.

2. Produce the initial hazard log before any significant design decisions are made. The hazard log drives the argument structure. Starting the safety case after the design is mature means fitting the argument to the design rather than using the argument to shape the design.

3. Establish the traceability infrastructure at program start, not at certification time. If requirements, design artifacts, and evidence are managed in a connected model from the beginning, the safety case traceability is built incrementally as the program progresses. Attempting to reconstruct it at the end is expensive and error-prone.

4. Define a change management process that explicitly includes safety case impact assessment. Every engineering change request should have a mandatory field: “Does this change affect any hazard mitigations or safety case evidence?” The answer is often no, but the question must be asked systematically.

A safety case is ultimately an argument made by engineers to other engineers — and to the public, through regulators — that they understand how their system can fail, what they have done about it, and why they believe the residual risk is acceptable. The structure and evidence requirements exist not to create compliance burden but to make that argument auditable and trustworthy. When it is built well, a safety case is one of the most valuable engineering artifacts a program produces.