rca-systems-theoretic

Systems-Theoretic RCA

Classical RCA asks "what component failed?" Systems-theoretic RCA asks "what control failed?" The difference is not cosmetic. An incident where no component is individually broken — every actor behaved plausibly, every tool worked as specified — is incomprehensible to classical techniques but natural to systems-theoretic ones.

This skill teaches you to treat incidents as control-structure failures rather than component failures, and to use STAMP-family techniques to find the actual design flaws.

The paradigm shift

| Classical RCA | Systems-theoretic RCA | |---|---| | Incidents are caused by component failures | Incidents are caused by inadequate constraints on system behavior | | Find the broken part | Find the broken control loop | | Human error is a root cause | Human error is a symptom of a control failure upstream | | Linear causal chains | Feedback loops and emergent behavior | | "Blame the operator" outcome | "Redesign the feedback mechanism" outcome |

The shift originates in Nancy Leveson's Engineering a Safer World (MIT Press, 2011) and her decades of work investigating Challenger, Columbia, Therac-25, and other complex-system accidents.

Framework 1 — STAMP: Systems-Theoretic Accident Model and Process

The core claim

Safety is a control problem, not a reliability problem. A system is safe if and only if it enforces the constraints that keep it in the safe state space. Accidents occur when these constraints are inadequate, missing, or violated — not necessarily because a component broke.

The STAMP model components

1. Controlled process — the physical or logical system being operated.
2. Controllers — agents (human, software, automated) that issue control actions.
3. Control actions — commands that move the controlled process between states.
4. Feedback — information flowing from the controlled process back to the controller.
5. Process model — the controller's internal representation of the controlled process state.

Accidents occur when the process model diverges from reality and the controller issues an inadequate control action based on the wrong mental model. This is the formal reframing of "situational awareness failure."

The four types of unsafe control action

STAMP classifies every control failure into one of four categories:

| # | Type | Example | |---|---|---| | 1 | A required control action is not provided | Pilot doesn't call go-around when needed | | 2 | An unsafe control action is provided | Autopilot engages descent while below glidepath | | 3 | A control action is provided at the wrong time or in the wrong order | Air traffic controller clears aircraft before previous landing cleared runway | | 4 | A control action is stopped too early or applied too long | Medical device infusion continues past intended dose |

Leveson's ten STAMP principles (from Engineering a Safer World)

1. Safety is an emergent property — it cannot be tested into a component.
2. Accidents are caused by inadequate control, not just component failure.
3. Safety constraints must be enforced at every level of the control hierarchy.
4. Human operators adapt their behavior to the actual work environment, not the designed one.
5. Organizations tend to drift toward unsafe states under economic pressure.
6. Human error is a symptom of system design, not a cause.
7. Classical hazard-analysis techniques (FTA, FMEA) address only component failures and miss control structure flaws.
8. Process models in controllers' heads diverge from reality over time — feedback must be designed to re-synchronize them.
9. Software safety is a control problem, not a reliability problem.
10. Accident investigation must examine the whole socio-technical control structure, not just the proximate event.

Framework 2 — STPA: System-Theoretic Process Analysis

STPA is the proactive hazard-analysis application of STAMP. Use it before the accident, in place of (or alongside) FTA/FMEA. It has four steps.

Step 1 — Define the purpose of the analysis

• Losses: what are the unacceptable losses? (death, data loss, financial loss, mission failure)
• Hazards: system states that can lead to losses given worst-case environment.
• System-level constraints: conditions the system must prevent or enforce.

Step 2 — Model the control structure

Draw the hierarchical control structure: controllers, controlled processes, control actions going down, feedback going up. Include humans, software, and physical components. The structure should look like a nested set of feedback loops.

Step 3 — Identify unsafe control actions (UCAs)

For each control action, ask: which of the four types of unsafe action could cause a hazard? Produce a UCA table:

| Control Action | Not Provided | Provided | Wrong Time/Order | Stopped/Duration | |---|---|---|---|---| | Landing gear extend | H1: aircraft touches down without gear | — | H2: gear extends after flare | — | | Autopilot disconnect | H3: pilot unaware, manual input clashes | — | — | — |

Step 4 — Identify loss scenarios

For each UCA, ask: why might this happen? This is the step where root causes emerge. Loss scenarios fall into categories:

• Controller flaws: wrong process model, inadequate algorithm, missing input.
• Feedback flaws: missing, delayed, wrong, or noisy feedback.
• Control action execution flaws: command sent but not executed, delayed, wrong.
• Coordination flaws: multiple controllers interfering.

Empirical evidence for STPA

Paper 2 of our systems-theoretic research (quantitative STPA studies) found STPA identifies hazards that FTA/FMEA miss — typically software-related and multi-controller interaction hazards — while also finding most of the hazards classical techniques find. Case studies in aviation (FAA), nuclear (MIT LNS), medical devices, and autonomous vehicles consistently report STPA uncovering scenarios not present in prior FTA.

Framework 3 — CAST: Causal Analysis based on STAMP

CAST is the retrospective incident-investigation application of STAMP. Where STPA looks forward, CAST looks back.

CAST process

1. Identify the system and losses. What happened, what was lost?
2. Identify system hazards. What hazardous states led to the loss?
3. Document the control structure at the time of the accident.
4. Analyze each component's role: What control actions were issued/not issued, and what process model did the controller have?
5. Examine the context: environmental, organizational, economic pressures that shaped behavior.
6. Identify systemic factors: communication, coordination, design, safety culture.
7. Recommend improvements to the control structure — not "operator training" unless training gaps are genuinely the highest-leverage intervention.

The CAST question discipline

For every human action that contributed to the accident, ask:

• What information did the actor have at that moment?
• What process model did they hold?
• Why was that process model reasonable given their inputs?
• What feedback could have corrected it?
• What pressures shaped their decision?
• What did the system design enable or prevent?

A CAST investigation is done when you can explain the accident to someone who believes the operators were competent professionals, and they agree the accident was foreseeable from the control structure.

Framework 4 — Rasmussen's Dynamic Safety Model

Jens Rasmussen's (1997) risk-management framework describes organizations operating in a space bounded by three boundaries:

                 Boundary of economically acceptable workload
                         ↑
         Marginal zone  │
                         │
  Operating ───────────→│← Normal operating range
    point               │
                         │
         Marginal zone  │
                         ↓
                 Boundary of acceptable workload / ac