A hardware engineer on a defense electronics program put it plainly in a working group last year: “I know what the safety standard requires us to submit. I don’t know what a safety case actually is. Is it a Word document? A binder? A model? And who’s supposed to be building it — the safety team or the engineers?”

That question is more common than the standards community tends to admit. The official definitions — “a structured argument supported by evidence” — are accurate but leave practicing engineers without a mental model of what the artifact looks like, how it gets built, or why it is often a disaster when treated as a documentation task rather than an engineering activity.

This article answers those questions concretely.

What a Safety Case Actually Is

A safety case is a reasoned argument that a specific system, in a specific operational context, is acceptably safe to deploy or operate. Three words in that definition carry most of the weight.

Reasoned means the argument is explicit. You are not asserting that the system is safe — you are showing why it is safe, step by step, in a way that a technically competent reviewer who was not on your team can follow and challenge. If a reviewer has to take your word for any step in the argument, that step is not yet a safety case; it is an assertion.

Specific means the argument is scoped. A safety case is not a general claim about good engineering practice. It is a claim about this system, these hazards, this operating environment, these mitigations, supported by this evidence. Generality is the enemy of a defensible safety case. The moment an argument could apply equally to a different system, it is too abstract to be trusted.

Acceptably safe — not “safe,” not “proven safe.” Every deployed engineering system carries residual risk. The safety case argues that the residual risk is below a defined threshold and that the argument for that conclusion is sound. The threshold comes from the applicable standard (DO-178C, IEC 61508, DEF STAN 00-056, ISO 26262, MIL-STD-882, depending on your domain), not from the engineering team’s comfort level.

The Two Dominant Argument Frameworks: GSN and CAE

You cannot construct a safety case without a notation for expressing structured arguments. Two frameworks dominate in practice.

Goal Structuring Notation (GSN)

GSN, standardized in GSN Community Standard v3, provides a graphical vocabulary for argument structure. The core elements:

  • Goals (rectangles): Claims you are making. “The system is acceptably safe in Mode A” is a goal. Goals can be decomposed into sub-goals.
  • Strategies (parallelograms): The argument pattern linking a goal to its supporting sub-goals. “Argument by demonstration of hazard elimination and residual risk mitigation” is a strategy. Without an explicit strategy, you have a list of claims, not an argument.
  • Solutions (circles): The actual evidence that grounds the argument — test records, analysis reports, inspection results, FMEA outputs.
  • Contexts (rounded rectangles): The scope, environment, or assumptions that bound the argument. These are critical. A claim that is true in one context may be false in another.
  • Assumptions (rounded rectangles with A): Things the argument depends on that are not themselves proved. Assumptions must be flagged explicitly and managed; if an assumption is violated, the argument breaks.
  • Justifications: Rationale for argument choices — why this decomposition, why this evidence type.

GSN’s power is that it makes the logical structure visible. A well-constructed GSN tree lets a reviewer quickly identify where the argument is strong (leaf nodes with solid evidence) and where it is weak (undischarged goals, unsubstantiated assumptions, evidence that does not clearly support the claim above it).

Claim-Argument-Evidence (CAE)

CAE is a simpler, more domain-agnostic notation that underpins much of the academic literature on assurance cases. The structure is hierarchical:

  • Claims: Statements asserted to be true (“Software component X does not exhibit buffer overflow conditions”)
  • Arguments: The reasoning connecting a claim to its supporting evidence or sub-claims (“Argument by static analysis and code review”)
  • Evidence: The artifacts that support the argument (“Coverity analysis report v2.3, clean run; code review record CR-2025-441”)

CAE maps directly onto GSN — Goals become Claims, Strategies become Arguments, Solutions become Evidence — but CAE is often easier to implement in text-based or tabular tools without dedicated GSN modeling environments. Many organizations use GSN for top-level system arguments and CAE for component-level or software assurance sub-cases.

Which Framework Should You Use?

If your standard or acquirer specifies one, use that. If you have a choice: GSN is better for communicating argument structure to reviewers unfamiliar with the system; CAE is easier to maintain in engineering tooling without a dedicated modeling environment. Large programs often use both.

What Evidence Is Admissible

This is where safety cases fail most often. Teams collect large volumes of documentation and call it evidence. Regulators and independent safety assessors (ISAs) reject arguments where evidence does not actually discharge the claim it is supposed to support.

Admissible evidence must satisfy four conditions:

1. Relevance. The evidence must directly address the claim above it. A full-system FMEA is not evidence that a specific software function handles sensor dropout gracefully — it may mention the scenario, but relevance requires specificity.

2. Currency. Evidence must reflect the system as-built or as-verified, not an earlier configuration. A test report from an architectural baseline that has since changed does not support a claim about the current baseline. Configuration traceability is non-negotiable.

3. Sufficiency. The evidence must be sufficient to justify the claim given the argument pattern. A single test run may be sufficient evidence for a deterministic function; it is insufficient evidence for a claim about probabilistic failure rates. The argument pattern (strategy/argument) must match the evidence type.

4. Independence. For high-integrity systems, evidence from the same team that produced the artifact being assessed carries less weight than evidence from an independent review or test. The required degree of independence scales with the Safety Integrity Level (SIL) or Design Assurance Level (DAL).

Common evidence types that appear in hardware and embedded systems safety cases: Hazard analysis records (PHA, HAZOP, FMEA, FTA), test records (unit test, integration test, hardware-in-the-loop, environmental qualification), inspection and review records, analysis outputs (simulation results, stress analysis, EMC analysis), design artifact snapshots (schematics, BOM at verified configuration), and safety requirement verification records (the specific link between a derived safety requirement and its verification evidence).

Why “Write It at the End” Fails

Most safety case failures in practice trace back to the same process mistake: the engineering team builds the system, then the safety team assembles a safety case to describe what was built. This approach fails for three compounding reasons.

Evidence cannot be reconstructed retroactively. Test data recorded without traceability to specific requirements, design decisions made without rationale, review records that do not exist because the review was informal — these cannot be fabricated after the fact without creating a fraudulent safety case. Evidence must be captured at the time the engineering work is done.

Arguments reveal gaps that require engineering responses. When you structure a safety argument, you discover that certain claims lack evidence, that certain hazards have incomplete mitigation chains, that certain assumptions are unverifiable. These gaps require engineering work — additional testing, design changes, analysis. Discovering them at program end means either accepting an unsupported argument or scrambling through regression and re-test. Neither is acceptable.

Living systems need living safety cases. For any system that undergoes modification after initial certification, the safety case must be maintained. A safety case built as a one-time document cannot be updated efficiently. When the argument structure, evidence, and design artifacts exist in separate repositories with no automated traceability, any modification requires a forensic reconstruction of what the argument was and what it now needs to be.

Building the Safety Case Iteratively

A safety case built correctly is an engineering artifact developed in parallel with the system. The practical sequence looks like this:

Phase 1 — Argument skeleton at system requirements. Before detailed design, draft the top-level goal structure. Identify the high-level hazards, the claim you will make about each, and the argument pattern you intend to use (argument by elimination, argument by mitigation to acceptable level, argument by independence). Flag what evidence types you will need to generate. This is not a final document — it is a commitment structure that will drive engineering decisions.

Phase 2 — Decompose claims as design decisions are made. As the architecture is established, decompose top-level safety goals into subsystem- and component-level claims. Each allocation of a safety function to a hardware or software element creates a new obligation: you now need evidence that the element meets the safety function allocation. Record design rationale — why this architecture, why this component, why this redundancy scheme — because rationale is part of the argument.

Phase 3 — Discharge evidence obligations as verification is completed. For each leaf-level claim, the verification activity that discharges it should be planned and tracked. When the verification activity is completed, the evidence artifact is linked to the claim it discharges. At this point the claim node in your argument changes state from “open” to “evidenced.”

Phase 4 — Argument review at major milestones. At CDR, at qualification test entry, at acceptance, review the argument structure: Are all claims evidenced? Are there undischarged assumptions? Has any engineering change invalidated a previously closed claim? This review is the equivalent of a unit test for the safety case itself.

Phase 5 — Configuration management of the argument. The safety case at acceptance is a snapshot. Subsequent modifications trigger a change impact process: which claims does this change potentially invalidate? What re-verification is required? The argument structure is the map for this analysis.

How Modern Tooling Makes This Tractable

The reason iterative safety case development has historically been painful is tooling fragmentation. Requirements live in one tool. Design artifacts live in another. Test records live in a third. The safety case document lives in a fourth. Traceability between them is maintained by a human process — which means it degrades as the program progresses.

Tools that connect requirements, design decisions, and verification evidence in a shared graph rather than synchronized documents change what is tractable. When a requirement node, the design decision that implements it, and the test record that verifies it are objects in the same model — rather than entries in separate spreadsheets — the safety argument is partially self-building. You are not writing linkages into a document; you are asserting that linkages exist between objects that already exist in the model.

Flow Engineering takes this approach explicitly for hardware and systems programs. Its graph-based requirements model lets teams connect safety requirements to the design elements that implement them and the verification records that discharge them, keeping the argument structure synchronized with the current engineering baseline rather than with the last time someone updated a document. When a design change occurs, the model shows which downstream claims and evidence links are affected — turning change impact analysis from a manual audit into a query.

This is not incidental. Safety case tractability is precisely the problem that graph-based, AI-native requirements tooling is better suited to solve than document-based tooling. The safety argument is fundamentally a graph — claims connected to sub-claims connected to evidence. Representing it natively as a graph rather than as formatted text removes the structural impedance mismatch between how the argument works and how it is maintained.

Flow Engineering does not provide a dedicated GSN modeling environment — teams that need full graphical GSN authoring with the GSN Community Standard notation typically use specialized assurance case tools alongside it. The value Flow Engineering adds is in keeping the underlying requirements, design, and evidence connected and current, so that whatever notation you use to express the argument, the supporting artifacts it references are not stale.

Practical Starting Points

If you are starting or inheriting a safety case effort:

Start with the hazard log, not the safety case document. The hazard log is the ground truth. Every top-level claim in your safety case should trace to a hazard being eliminated, controlled, or accepted. If you cannot show that connection, the claim is floating.

Write the argument before you write the evidence section. Identify what you need to prove and how you intend to prove it before you look at what evidence you have. Starting from available evidence produces an argument that defends what was done rather than an argument that the system is safe.

Distinguish assumptions from claims. Every assumption that cannot be substantiated is a risk to your argument. List them explicitly, make them visible to reviewers, and have a plan for what happens if one is violated.

Treat every safety requirement verification as a safety case closure event. When a test closes a safety requirement, that is the moment to link the test record to the claim it discharges. Not at the end of the program.

Plan for your safety case to be wrong. You will discover gaps. The argument structure is designed to show you where they are so you can fix them during engineering, not during a certification review.

A safety case done right is not a document that describes a safe system. It is a structured, traceable argument that the system is safe — one that any technically competent reviewer can audit, challenge, and accept on its merits. The engineering work that makes the system safe and the argumentative work that demonstrates it are not separate activities. They are the same program, run together.