Glossary

A reference for the terms used throughout the documentation. GSN-spec terms first, then domain-specific terminology grouped by industry.

GSN notation

Goal — A claim or assertion about the system. The core building block of every assurance argument. Renders as a blue rectangle in Lemmatica.

Strategy — The reasoning approach used to decompose a Goal into sub-Goals. Renders as an orange parallelogram.

Solution — A leaf node pointing at evidence (a test report, an analysis, a review record). Renders as a green circle.

Context — Environmental information that scopes a claim — definitions, system boundaries, operating conditions. Renders as a purple rectangle. Attaches to any structural node via an InContextOf edge.

Assumption — Something accepted as true without proof within the argument. Renders as a pink rectangle.

Justification — Rationale for why a particular approach or decomposition is appropriate. Renders as a cyan rectangle.

Away goal — A leaf goal in one document that references another document where the argument continues. Enables modular decomposition across teams or sub-cases.

Undeveloped goal — A goal explicitly marked as having no children yet. Lemmatica flags undeveloped goals so they're visible during review.

Defeater — A counter-argument raised against a Goal or Solution. Part of the GSN V3 dialectic extension.

Defeated state — When a Defeater is accepted, the challenged node becomes defeated. Defeat propagates upward through the argument tree.

SupportedBy — The parent-child edge type in the argument tree (Goal → Strategy, Goal → Solution, Strategy → Goal).

InContextOf — The edge type attaching annotation nodes (Context, Assumption, Justification) to structural nodes.

GSN Community Standard V3 — The current version of Goal Structuring Notation (SCSC-141C), maintained by the Safety-Critical Systems Club.

Aerospace

DO-178C — RTCA standard for software considerations in airborne systems and equipment certification.

DO-254 — RTCA design assurance guidance for airborne electronic hardware.

ARP4754A — SAE guidelines for development of civil aircraft and systems.

ARP4761A — SAE guidelines and methods for conducting the safety assessment process.

DAL (Design Assurance Level) — Software/hardware development rigour classification under DO-178C / DO-254, levels A (catastrophic) through E (no effect).

FHA (Functional Hazard Assessment) — Top-down analysis identifying functional failure conditions and their severity.

FTA (Fault Tree Analysis) — Top-down deductive analysis tracing how a failure condition can arise.

FMEA (Failure Mode and Effects Analysis) — Bottom-up analysis cataloguing component failure modes and their effects.

CCA (Common Cause Analysis) — Analysis identifying failures that could affect redundant components simultaneously.

Automotive

ISO 26262 — International standard for functional safety of road vehicles (Parts 1–12).

ISO 21448 (formerly ISO/PAS 21448) — Safety of the intended functionality (SOTIF). Addresses hazards from performance limitations rather than malfunctions.

SOTIF (Safety Of The Intended Functionality) — Shorthand for ISO 21448. Covers hazards arising from a correctly-functioning system encountering conditions outside its design assumptions.

UNECE R155 — UN regulation requiring cybersecurity management systems for road vehicles.

UNECE R156 — UN regulation requiring software update management systems for road vehicles.

ASIL (Automotive Safety Integrity Level) — ISO 26262 classification of safety relevance for each function: A (lowest) through D (highest), with QM (Quality Managed) below.

HARA (Hazard Analysis and Risk Assessment) — ISO 26262 step that identifies hazards, classifies severity/exposure/controllability, and derives Safety Goals.

FSC (Functional Safety Concept) — High-level allocation of safety requirements derived from Safety Goals.

TSC (Technical Safety Concept) — Lower-level allocation of safety requirements to the technical architecture.

FMEDA (Failure Modes, Effects and Diagnostic Analysis) — ISO 26262 hardware analysis demonstrating that random hardware failure metrics meet ASIL targets.

Autonomous vehicles

UL 4600 — Underwriters Laboratories standard for safety for the evaluation of autonomous products. Explicitly assurance-case-driven.

ODD (Operational Design Domain) — The specific conditions under which an automated driving system is designed to operate (geography, road type, weather, speed range, etc.).

L3 / L4 — SAE J3016 levels of driving automation. L3: conditional automation (driver may need to take over). L4: high automation within the ODD.

Cybersecurity

ISO/IEC 15408 — Common Criteria for Information Technology Security Evaluation.

ISO/SAE 21434 — Road vehicles cybersecurity engineering.

NIST SP 800-53 — Security and Privacy Controls for Information Systems and Organizations.

NIST SP 800-160 — Engineering Trustworthy Secure Systems (vol 1) and Developing Cyber-Resilient Systems (vol 2).

STRIDE — Microsoft threat-model categories: Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.

WebAuthn — W3C standard for public-key-based authentication, the technical basis for phishing-resistant 2FA.

Medical devices

IEC 62304 — Medical device software lifecycle processes. Defines software safety classes A, B, C.

ISO 14971 — Application of risk management to medical devices. The harm/hazard/risk model.

IEC 62366-1 — Application of usability engineering to medical devices.

IEC 60601-1 — General requirements for basic safety and essential performance of medical electrical equipment.

510(k) — FDA premarket notification submission demonstrating substantial equivalence to a legally-marketed device.

De Novo — FDA pathway for novel low-to-moderate risk devices without a predicate.

PMA (Premarket Approval) — FDA's most stringent pathway, for high-risk devices.

TGA (Therapeutic Goods Administration) — Australia's medical device regulator.

MHRA (Medicines and Healthcare products Regulatory Agency) — UK's medical device regulator.

Cross-cutting

Safety case — A structured argument, supported by evidence, that a system is acceptably safe for its intended use in its operating environment.

Assurance case — The general form — a structured argument that a system is fit for purpose for some attribute (safety, security, reliability, ethics, etc.).

Safety-critical — Domain adjective for systems where failure can cause harm. Common in aerospace, automotive, medical, rail, and nuclear contexts.