Summary

  • Nancy Leveson's STAMP treats safety as a property of a whole control system, rather than a number obtained by adding up reliable parts.
  • STPA looks ahead for hazardous control actions and their causes; CAST works backward from a loss to understand how the safety control structure allowed it.
  • Neither method predicts every accident or replaces component testing. The practical test is whether constraints, decisions and feedback stay aligned as the system changes.

Imagine a vehicle that refuses to apply a braking command until its sensors report the expected operating mode. The sensors report faithfully, the software executes its rule, and the operator presses the control. Yet the road, timing and mode transition make the refusal dangerous. Asking which component broke may leave the central question unanswered: why did the design make that command conditional on a picture of the world that could be wrong?

That is the opening Nancy Leveson gave system safety. Her MIT profile identifies her as a professor of aeronautics, astronautics and engineering systems whose work spans software, organizations and human interaction. In a 2002 accident-model paper, she argued that investigation should reach beyond blame and isolated failure to the social and technical arrangements that shape decisions. Her 2012 book Engineering a Safer World developed this argument into STAMP, the Systems-Theoretic Accident Model and Processes.

Reliability asks whether a component performs its specified function. Safety asks whether the interacting system avoids unacceptable losses. The questions overlap: broken components can be hazardous. But a set of reliable components can still interact in an unsafe way. A control rule may be correct for one mode and dangerous in another; two controllers may issue incompatible instructions; a delayed status report may leave a human or machine acting on yesterday's state. Safety therefore cannot be certified by component reliability alone.

Leveson's framework begins by naming a loss—an outcome the people responsible for the system cannot accept, such as injury. A hazard is a system condition that can lead to that loss in a relevant environment. The distinction matters. Hazard analysis can intervene before anyone is hurt. A safety constraint then states the condition the system must enforce or prevent. The analyst has to draw the system boundary honestly: it may include a device, operator, maintenance team, managers and regulators, not just a box of electronics.

Within that boundary, a controller sends a control action to a controlled process and receives feedback. The controller may be software, a person or an organization. It acts through a process model, its working account of the process and surrounding conditions. If a sensor is late, a report is suppressed, or two teams use incompatible assumptions, the model can diverge from what is happening. A controller can then act consistently with its own information and still violate a safety constraint.

This is why an unsafe action is more precise than a vague label of “human error.” The STPA Handbook, written by Leveson and John P. Thomas, asks whether a hazardous command was supplied, a necessary command withheld, a command given too early or too late or in the wrong order, or an otherwise useful action ended too soon or continued too long. Context, not the command's name, determines safety. Analysts then trace how the controller's model, feedback path, authority and operating pressures could produce that action.

STAMP is the causal model behind this work; it is not itself a completed analysis. STPA applies it prospectively: define losses, hazards and constraints; model the control structure; identify unsafe control actions and plausible causal scenarios; then feed the results into requirements, design and operations. A neat diagram without those questions and scenarios is a sketch, not STPA. CAST uses the same systems perspective after an event. It reconstructs how controls at multiple levels operated, what information decision makers had, and why constraints failed, so the lesson is broader than naming the person nearest the loss. MIT's handbook collection explicitly distinguishes STPA's prospective hazard work from CAST's retrospective learning.

The intellectual credit is both clear and shared. Leveson formulated STAMP and built a sustained research programme around it. Thomas co-authored the STPA Handbook and developed teaching and practice. MIT workshop records identify William Young's work on security applications, Shem Malmquist's CAST instruction and Cody Fleming's early-concept and application work. MIT's publication catalogue places Nicolas Dulac and Joel Cutcher-Gershenfeld in adjacent system-safety and organizational research. The Partnership for Systems Approaches to Safety and Security, practitioners and the older systems and control-theory tradition all helped turn a model into usable inquiry. None of those credits requires claiming that one person invented every safety method.

The promise has a boundary. STPA can expose scenarios that a failure-chain analysis overlooks; it cannot enumerate every possible future interaction. CAST can explain why a control structure permitted a known loss; it cannot recover information never recorded. Both depend on a defensible system boundary, current operating evidence, people who understand the work, and a willingness to change design or authority when the analysis finds a gap. Conventional reliability engineering still matters for failures that really are component failures. Leveson's contribution was to make that necessary work insufficient as the sole account of safety.

Sources