Aerospace

Aerospace safety arguments are some of the most mature in industry. Decades of regulator-driven process — RTCA in the US, EUROCAE in Europe — produced a stack of standards that nobody gets to ignore.

GSN didn't originate in aerospace, but it slots into the assurance work that has to happen anyway: the argument that a system, given its evidence, is acceptably safe for its intended use.

The standards stack

The standards most often cited in airborne assurance work:

• DO-178C — Software Considerations in Airborne Systems and Equipment Certification
• DO-254 — Design Assurance Guidance for Airborne Electronic Hardware
• ARP4754A — Guidelines for Development of Civil Aircraft and Systems
• ARP4761A — Guidelines and Methods for Conducting the Safety Assessment Process

These describe what the assurance process must look like. They don't prescribe the notation you use to present the argument. That's where GSN earns its keep.

What GSN gives you

A traditional aerospace safety case is a stack of analyses, test reports, design documents, and review records. The argument that ties them together — why this body of evidence is enough — is typically prose, scattered across multiple documents, and read sequentially.

GSN makes that argument explicit and graphical:

• Top-level claim: the system is acceptably safe for its intended function within its operating envelope.
• Decomposition strategies: by Functional Hazard Assessment (FHA), by item, by failure condition, by Design Assurance Level (DAL).
• Sub-claims: each hazard mitigated, each function correctly implemented, each failure condition handled to its DAL.
• Evidence (Solutions): the FHA, FTA, CCA, requirements traceability matrix, verification results, configuration management records.

The argument becomes reviewable as a whole, rather than as a stack of separate documents whose interdependencies live in the assessor's head.

An example fragment

A high-level argument for a fly-by-wire control law, decomposed by the ARP4761 failure-condition classifications:

Each sub-Goal terminates in Solutions — the FTA reports, FMEA records, and DAL-A development evidence that justify the claim.

Where Lemmatica fits

• DAL-A / DAL-B development typically involves multiple engineers across hardware and software disciplines. Real-time collaboration on the argument reduces the merge-conflict overhead of file-based tools.
• Modular sub-cases via away goals let you separate the argument by item, by ATA chapter, or by certification phase, while maintaining traceability to the top-level claim.
• Continuous validation catches structural errors — orphaned goals, undeveloped branches, missing context — early, rather than during a formal review weeks later.
• Dialectic extension (planned) gives you a place to record assessor challenges and their resolution within the argument itself, not in parallel correspondence.