Faa system safety

<!-- argument-hint: [risk management step, hazard analysis activity, analysis technique, risk matrix, order of precedence, software/launch/facility/ORM domain, chapter number] -->

FAA System Safety Handbook

Source: FAA (US Government work, public domain) | Chapters: 7

When to use

Use this skill to run system safety as a specialty within systems engineering: framing safety risk management around stated acceptance criteria, describing the system, identifying and analyzing hazards by severity and likelihood, choosing controls down a fixed order of precedence, selecting the right analytical technique, and tracking every hazard to verified closure. It also covers the handbook's specialty domains — acquisition-lifecycle safety and contracting, software safety, test and facilities safety, commercial launch licensing, training, and field-level Operational Risk Management. It is the FAA's "how-to" companion to the policy in FAA Order 8040.4 and the Acquisition Management System.

Prerequisites: none — plain Markdown; no MCP server, API key, or licence tier needed at runtime.

How to Use This Skill

• Without arguments — load the core frameworks below: the five-step process, the risk matrix, the Safety Order of Precedence, the 5M/SHEL(L) models, the hazard-analysis activities, and the analysis-technique toolkit.
• With a topic — ask about a risk management step, a hazard-analysis activity (PHA, SSHA, SHA, O&SHA…), an analysis technique (FTA, FMECA, CCFA, Sneak Circuit, Energy Trace), the risk matrix, the order of precedence, or a specialty domain (software, launch, facilities, ORM).
• With a chapter — ch01 (foundations), ch03 (integrated hazard analysis + activities), ch04 (analysis techniques), ch07 (ORM and human factors).

Supporting files: glossary.md, patterns.md, cheatsheet.md.

One engine, many casings. The whole handbook runs one loop: describe the system, identify hazards, characterize risk by severity and likelihood, control it down the order of precedence, verify, and track to closure. Chapters 1–4 establish that engine; chapters 5–7 apply it to software, test, facilities, launch, training, and operations.

Core Frameworks & Mental Models

What system safety is (FAA framing)

In the FAA's view, system safety is a specialty within systems engineering whose job is to support program risk management — find the risks that matter, then eliminate or control them through design and procedure, in a defined order of preference, across the whole life cycle. It is made mandatory by FAA Order 8040.4 (1998) and carried into acquisition by the Acquisition Management System (AMS). The handbook is deliberately a "how-to"; the when/who/why live in the safety plans it points to (SSMP / SSPP / ISSPP). Safety is balanced against cost, schedule, and performance — there is no zero-risk goal; some risk must be accepted, and that is management's decision.

The five-step safety risk management process

Order 8040.4 frames the discipline as five steps: Plan (set the process and fix the risk-acceptability criteria up front), Identify the hazards, Analyze them by severity and likelihood, Assess them against the plan's criteria (the Comparative Safety Assessment), and Decide — with management owning the residual risk. Qualitative or quantitative assessment is allowed, with a stated preference for quantitative; assumptions must be conservative and documented.

Risk = severity × likelihood → acceptance band

A hazard is a condition that could lead to an undesired event; risk couples severity of consequence with likelihood of occurrence, and both must be characterized. The FAA AMS severity scale runs Catastrophic → Hazardous → Major → Minor → No Safety Effect; the likelihood scale runs Probable → Remote → Extremely Remote → Extremely Improbable. The two combine in a Risk Acceptability Matrix yielding High / Medium / Low bands — High is tracked until reduced, Medium is acceptable only with management review, Low needs no further tracking. (MIL-STD-882C renames the bands R1–R4.) The coupling matters: the more catastrophic the outcome, the lower its allowable probability — fix severity first, then read across to the probability the design must achieve.

The Safety Order of Precedence

The fixed hierarchy for treating any hazard: (1) design for minimum risk (eliminate by design), (2) incorporate safety devices, (3) provide warning devices, (4) develop procedures and training. Procedures/training is the least-preferred option for severe hazards and normally needs concurrence of authority. For a fielded system, redesign is often not cost-effective, so revising procedures becomes the fastest route — but it only cuts likelihood or severity, it does not remove the hazard.

System-description models: 5M and SHEL(L)

Before any risk work, describe the system. The 5M model decomposes it into Mission, Man, Machine, Management, and Media; the SHEL(L) model uses Software, Hardware, Environment, and Liveware (human). Both force the analyst to examine every element and every interface — interface matches and mismatches matter as much as the elements themselves. Description trades breadth against depth: a wide system (the NAS) gets a general description; a narrow component gets a detailed one.

The hazard-analysis activities (lifecycle order)

Seven design-phase activities run in lifecycle order: PHL (early hazard seed list carried into the RFP) → PHA (the foundational analysis, before preliminary design review) → RHA (turns hazards into design requirements) → SSHA (component → whole) → SHA (whole + interfaces → subsystem safety) → O&SHA (procedurally controlled operation/support, usually completed last) → HHA (hazardous materials). A proactive program shapes the design via the PHL before it starts; a reactive one justifies redesign after milestones.

Integrated system hazard analysis

An accident in a complex system is almost never a single failure, so neither a single technique nor a single analysis can capture the risk. Integrated system hazard analysis logically combines the separate analyses around human–machine–environment interactions — reasoned integration, not stapled reports. Risk is a chain: an initiating hazard plus contributory hazards (unsafe acts, unsafe conditions) leads to a primary catastrophic/critical event. A failed safeguard is itself a hazard. Reliability and safety are complementary but not interchangeable — a reliability failure rate is usually too coarse to satisfy a safety requirement.

The analysis-technique toolkit

Hazards present from two directions, so the techniques are chosen to cover each other's blind spots:

• Event-driven / top-down (deductive) — Fault Tree Analysis (FTA) maps failure paths down from one defined undesired event; Fault Hazard Analysis is a safety-focused subset of an FMEA.
• Consequence-driven / bottom-up (inductive) — FMEA / FMECA walk component failures up to their effects; FMECA adds a purpose-specific criticality figure of merit (hardware/software only).
• Specialty — Common Cause Failure Analysis (CCFA) extends FTA to test whether redundancy is real; Sneak Circuit Analysis finds latent conditions that misbehave with no component failing; Energy Trace inventories controlled/uncontrolled energy and seeds fault-tree top events.

Always do the qualitative pass first; quantify only when the value justifies the cost and the limits of the numbers are explicit. A recurring caution: false precision — chasing exact numbers from inexact data — is one of the field's biggest pitfalls.

Closed-loop hazard tracking

Hazard Tracking and Risk Resolution makes risk control a closed loop, gated by explicit management risk acceptance. The Safety Action Record (SAR) carries each hazard's description, causes, initial and residual risk, suggested and implemented controls, verification and validation, and the concurrences required to close it. A hazard is closed only after its controls are verified, and residual risk is knowingly accepted and documented.

Operational Risk Management (the operational counterpart)

Where the hazard analyses engineer safety into a system before it is fielded, ORM manages risk while the system is operated, run pre-emptively (e.g., before each flight). It is a six-step loop — identify, assess, analyze controls, decide, implement, supervise/review — governed by four principles (accept no unnecessary risk; decide at the level that controls the resources; accept risk only when benefits outweigh costs; integrate into planning at every level). Match rigor to the situation (time-critical / deliberate / strategic), drive controls up the user-involvement ladder toward user ownership, and measure risk directly rather than waiting on accident statistics. The 5M model and the human-as-most-variable-element framing carry into human factors and organizational data-sharing (GAIN, FOQA).

---

Chapter Index

#	Section	Key content
ch01	Foundations: policy, process, principles	Order 8040.4 / AMS / FAST chain; the five-step process; hazard vs. risk; severity/likelihood scales; the risk matrix and acceptance bands; CSA; the Safety Action Record; cost-vs-safety balance; Safety Order of Precedence; behavioral-based safety; 5M and SHEL(L)
ch02	Acquisition lifecycle, assessments & contracting	OSA (OSED/OHA) and CSA; ASOR and the Target Level of Safety; the SSPP as a binding baseline; the ISSPP; tailoring; GFE and COTS/NDI; the specification/SOW/CDRL/bidders'-instructions contract hooks
ch03	Integrated hazard analysis & analysis tasks	Integrated system hazard analysis; initiating/contributory hazards; risk as a chain; safety vs. reliability; the seven activities (PHL/PHA/RHA/SSHA/SHA/O&SHA/HHA); qualitative-before-quantitative; FTA mechanics, gates, and cut sets
ch04	Analysis techniques	Fault Hazard Analysis; Fault Tree Analysis (symbology, cut sets); Common Cause Failure Analysis; Sneak Circuit Analysis; Energy Trace; FMECA; the deductive-vs-inductive axis; named pitfalls
ch05	Software, test & facilities safety	The five-step software safety process; Software Safety Working Group; control-capability ranking and the SHCM; DO-178B levels; test as both evidence and hazard; the Facility Acquisition Life Cycle; ORMG; facility risk categories; conformance-is-a-floor
ch06	Commercial launch safety & training	AST licensing; expected casualty; Maximum Probable Loss and DAMP; the Validation Acceptance Matrix (analysis/ground test/flight test); the Systematic Software Safety Process; the training method (needs → task → objectives → delivery → learning styles)
ch07	Operational Risk Management & human/organizational factors	The six-step ORM process and four principles; types-of-risk taxonomy; the 5-M model; three levels of risk management; user-involvement and command-involvement ladders; GAIN, FOQA, ASPRAM; human factors and the Total System Concept

Topic Index

• Acquisition lifecycle / AMS / IPDS → ch01, ch02
• ASOR / Target Level of Safety → ch02
• Behavioral-based safety / safety culture → ch01
• Comparative Safety Assessment (CSA) → ch02, ch01
• Common Cause Failure Analysis (CCFA) → ch04
• Contracting / SOW / CDRL / specification → ch02
• Contributory and initiating hazards → ch03, ch01
• Cost-versus-safety balance → ch01
• Cut sets / minimal cut sets → ch04, ch03
• DAMP / Maximum Probable Loss (MPL) → ch06
• Energy Trace → ch04
• Expected casualty → ch06
• Facilities safety / Facility Acquisition Life Cycle → ch05
• Fault Hazard Analysis → ch04
• Fault Tree Analysis (FTA) → ch04, ch03
• FMEA / FMECA → ch04, ch03
• Hazard versus risk → ch01
• Hazard analysis activities (PHL/PHA/RHA/SSHA/SHA/O&SHA/HHA) → ch03
• Hazard tracking / Safety Action Record (SAR) → ch01
• Health Hazard Assessment (HHA) → ch03
• Human factors / Total System Concept → ch07
• Integrated system hazard analysis → ch03
• Launch licensing / AST → ch06
• Operational Risk Management (ORM) → ch07
• Operational Safety Assessment (OSA / OSED / OHA) → ch02
• Order 8040.4 / policy spine → ch01
• Preliminary Hazard Analysis (PHA) → ch03, ch01
• Preliminary Hazard List (PHL) → ch03, ch01
• Reliability versus safety → ch03
• Risk matrix / acceptance bands → ch01
• Safety Order of Precedence → ch01, ch03, ch02
• Severity and likelihood scales → ch01
• SHEL(L) model → ch01
• Sneak Circuit Analysis → ch04
• Software safety / control capability / SHCM → ch05, ch06
• Software safety process (five-step) → ch05
• System Safety Program Plan (SSPP) / ISSPP → ch02, ch01
• Test and evaluation safety → ch05
• Training / learning objectives → ch06
• Voluntary safety data sharing (GAIN / FOQA / ASPRAM) → ch07
• 5M model → ch01, ch07, ch03

Supporting Files

• glossary.md — key system-safety terms, alphabetical, with chapter references
• patterns.md — reusable patterns (the five-step process, 5M/SHEL(L) description, coupling severity to probability, working the order of precedence, integrated hazard analysis, technique selection, software safety, ORM) with When / How / Trade-offs
• cheatsheet.md — quick decision rules, the five-step process, the risk matrix, the hazard-analysis activities, the technique table, acquisition hooks, and tells & smells

---

Scope & Limits

Covers: system safety as the FAA practiced and taught it in the System Safety Handbook (Dec 30, 2000) — the policy spine (Order 8040.4, the AMS), the five-step safety risk management process, the severity/likelihood scales and Risk Acceptability Matrix, the Safety Order of Precedence, the 5M and SHEL(L) system-description models, the seven hazard-analysis activities, integrated system hazard analysis, the analysis-technique toolkit (FTA, FMEA/FMECA, Fault Hazard, CCFA, Sneak Circuit, Energy Trace), closed-loop hazard tracking via the Safety Action Record, and the specialty domains the handbook addresses (acquisition-lifecycle safety and contracting, software safety, test and facilities safety, commercial launch licensing, training, and Operational Risk Management with human and organizational factors).

Thin on / does not cover: the source is a year-2000 how-to and predates the modern FAA/ICAO Safety Management System (SMS) and Just Culture regulatory frameworks — it gestures at the underlying ideas (non-punitive reporting, positive culture) but does not present SMS as later formalized. Many cited FAA orders, advisory circulars, and commercial-launch-licensing rules date to 2000 and have since been restructured — confirm current citations before relying on them. It is FAA/NAS-centric and leans heavily on MIL-STD-882C. It does not define the systems- engineering life-cycle processes themselves (use nasa-npr-7123 / dau-se-guidebook / nasa-se-handbook), nor does it reproduce third-party standard text — MIL-STD-882, RTCA DO-178B, NASA 8719.13A, and ISO/IEC/IEEE material is named and described in original words but not reprinted (for the broader landscape see se-standards-signpost; for the FAA's general SE process see faa-sem; for the defense severity matrix lineage see mil-std-882).

Source version: FAA System Safety Handbook, December 30, 2000 (the full 17-chapter handbook; this pack synthesizes it into 7 chapters). It is a US Government work in the public domain.