Defence

Defence assurance argumentation has the same shape as the safety- and security-critical work in adjacent industries, but it carries some extra weight: multi-national regulatory contexts, decade-plus lifecycles, prime-contractor / sub-contractor review chains, and the need to reason about safety, security, and mission assurance together rather than as separate documents.

GSN is one of the most widely-recognised notations in this space — UK MoD Def Stan 00-56 explicitly references assurance cases as the expected form, and similar expectations are emerging in other national frameworks.

The standards stack

Defence rarely runs on a single standard; the argument has to satisfy multiple, often simultaneously.

• Def Stan 00-55 — UK MoD requirements for the procurement of safety-related software
• Def Stan 00-56 — UK MoD safety management requirements for defence systems
• MIL-STD-882E — US DoD Standard Practice for System Safety
• STANAG 4404 — NATO software safety standard
• STANAG 4671 — NATO airworthiness requirements for military uncrewed aerial systems (UAS)
• DO-178C / DO-254 — also used for military airborne systems where civil airworthiness applies
• IEC 61508 — baseline functional safety, sometimes invoked under defence contracts

For Australian programs, the ASDEFCON contracting framework and Defence Materiel Manuals layer specific assurance expectations on top of the standards above.

What's different about defence

Three things shape the assurance argument:

• Multi-domain reasoning: a single platform usually needs concurrent arguments for safety (people, kit), cyber (information assurance), mission assurance (will it actually do its job), and increasingly autonomy (can it be trusted to operate). Trying to keep these in separate documents loses the cross-cutting story.
• Multi-stakeholder review: capability sponsor, technical authority, certification authority, operator, often a prime contractor and several sub-contractors. The argument needs to be readable as a single artefact across all of them.
• Long lifecycle: a defence platform's argument has to remain defendable through upgrades, redeployments, and operating-context changes spanning decades. Structural traceability matters disproportionately.

An example fragment

A fragment of an argument for a fictional military uncrewed aerial system (UAS), decomposed by hazard class per Def Stan 00-56:

Each sub-Goal terminates in Solutions — the specific analyses, test results, and authority assessments that justify the claim at the relevant Safety Integrity Level.

Where Lemmatica fits

• Multi-stakeholder collaboration with role-based visibility maps onto the prime contractor / sub-contractor / certifying authority review chains that defence programs run on.
• Modular sub-cases via away goals let separate teams own their slices (airframe, mission system, cyber, autonomy) while linking back to the top-level mission claim.
• Continuous validation is especially useful on programs where the argument evolves across years and reviewers — structural drift gets flagged immediately rather than at gate reviews.
• Long-lived argument as a single artefact suits the decade-plus lifecycle of a typical defence platform. Versioning, evidence traceability, and audit trail are first-class rather than after-thoughts.

A note on classification: Lemmatica today runs as a cloud service, which constrains its applicability for material that must stay air-gapped. On-premise deployment is on the roadmap and is the typical request for classified work.