Why use STAMP?

Mastering Complexity

Modern systems are no longer just collections of parts. They are complex, software-intensive, and deeply interconnected socio-technical systems. Traditional safety and security methods often struggle to keep pace with this interactive complexity.

STAMP (System-Theoretic Accident Model and Processes) introduces an effective way of thinking about system weaknesses and vulnerabilities. Instead of looking for “failed” components, individual “threats”, or “human error”, STAMP views safety and security as a feedback control problem. By enforcing constraints on system behavior through a functional control structure, vulnerabilities can be identified that traditional methods miss.

Explaining the “Why”

Traditional cause	STAMP view
“Operator error” “Operator violates established procedure”	Inadequate Mental Model. If the operator incorrectly believes the system is in State B rather than State A, they may execute a procedure that is functionally correct for the perceived state but catastrophic for the actual state. Because the system design does not provide a clear way to confirm the true state, it will cause human error.
“Software design error”	Missing Constraints. Software functionality A lacks the necessary safety constraint B to prevent hazards. Hazard X will be caused if the software correctly executes functionality A during context C.
“The conditions exceeded design limits”	Missing or Inadequate Feedback. No clear feedback exists to indicate exactly when design boundaries are being approached or crossed. As a result, decisions to operate may involve an incorrect assumption that the design limits are not exceeded.
“Simultaneous failure of redundant hardware is unlikely”	Incorrect Assumptions. The redundant components may not fail simultaneously. One component fails and a backup takes over as designed. However, feedback about the failure is not enabled, is not communicated, or the component is not repaired within X time as assumed. There is missing operational feedback to recognize when actual time to repair exceeds the value assumed by engineers. The system continues operating normally until the redundant component eventually fails.
“Automation failed”	Decision-making flaw. “Software Action_A is unsafe when B. However, software can default to Action_A when C, causing a hazardous condition.”

TRADITIONAL

CAUSES

“Operator error”
“Operator violates established procedure”
“Loss of situational awareness”
“Failure to execute the Challenge-Response protocol”

SOLUTIONS

Mandatory training to ensure all procedures are followed
Coaching session with senior lead to review the specific violation and its consequences
Conduct a “Line Check” to verify compliance

STAMP

VIEW

Inadequate Mental Model

If the operator incorrectly believes the system is in State B rather than State A, they may execute a procedure that is functionally correct for the perceived state but catastrophic for the actual state. Because the system design does not provide a clear way to confirm the true state, it will cause human error.

SOLUTION

Design the system to provide direct, independent feedback of the true state, and update procedures to include appropriate means to confirm the state.

REAL-WORLD EXAMPLE

In the Three Mile Island accident, operators followed procedures based on a mental model that a valve was closed, when it was actually stuck open. The valve position indicator was designed to indicate what the valve was commanded to do rather than measuring the actual position of the valve.

TRADITIONAL

CAUSE

“Software design error”

SOLUTION

Assign an assurance/integrity level to minimize the chance of an unknown error. Use rigorous software development practices, like increasing test coverage to catch more bugs. If a bug is found, fix it.

STAMP

VIEW

Missing Constraints

Software functionality A lacks the necessary safety constraint B to prevent hazards. Hazard X will be caused if the software correctly executes functionality A during context C.

SOLUTION

Define a software safety constraint to ensure __ is always provided by the software whenever ___ occurs. Remove functions A and B that contradict this constraint, and instead implement functions D and E to ensure the software cannot enter hazardous states regardless of user input.

REAL-WORLD EXAMPLE

The Therac-25 radiation accidents occurred because the software logic allowed a high energy beam to activate without a protective spreader in place, never enforcing a critical safety constraint during rapid operator input.

TRADITIONAL

CAUSE

“System operated in conditions that exceeded design limits”

SOLUTION

Warn operators not to exceed limits and improve training on technical specifications.

STAMP

VIEW

Missing or Inadequate Feedback

No clear feedback exists to indicate exactly when design boundaries are being approached or crossed. As a result, decisions to operate may involve an incorrect assumption that the design limits are not exceeded.

SOLUTION

Establish continuous “Safe Envelope” visualizations that show margins of safety in real time, and automate boundary enforcement (e.g., hard-coded lockouts) when sensors detect environmental parameters exceeding safety thresholds.

REAL-WORLD EXAMPLE

The Space Shuttle Challenger disaster involved operating outside the “safe envelope” for temperature. The decision was enabled by a weak control structure to address growing concerns and a management belief that there was no clear indication that design limits were exceeded.

TRADITIONAL

CAUSE

“Simultaneous failure of redundant hardware (unlikely)”

SOLUTION

Use quantitative reliability modeling (e.g., Fault Tree Analysis) to determine the probability of concurrent failures. Implement sufficient redundancy/diversity/independence to ensure the residual risk is acceptable.

STAMP

VIEW

Incorrect Assumptions

The redundant components may not fail together. One component fails, but the failure has minimal impact because a backup system immediately takes over. Feedback about the failure is not enabled, does not exist, or it exists but the component is not repaired within X time as assumed. There is poor or nonexistent feedback to management to recognize when actual time to repair exceeds the value assumed by engineers. The system continues operating normally until the redundant component eventually fails.

SOLUTION

Design the control structure to ensure explicit alerts to maintenance. Design leadership feedback to evaluate when the assumed time to repair is exceeded in operation. Define required responses at each level, including operators, maintenance, and leadership, when the redundant path is not repaired within a validated time limit. For example, certain operations may be halted or additional limits imposed until a full repair is completed.

REAL-WORLD EXAMPLE

The Deepwater Horizon Oil Spill involved two redundant control systems on the ocean floor: the Blue Pod and the Yellow Pod. Only one was needed to function, and the system was designed so that if one failed, the other could take over. However, there was no “hard” control that halted drilling if one pod went offline. Months before the explosion, the Blue Pod failed due to a dead battery. The Yellow Pod took over seamlessly. The rig continued to operate “normally”.

While there was some technical feedback that the Blue Pod was struggling, it wasn’t treated as a “stop-work” event. Management and leadership did not have a feedback loop to recognize that the Mean Time to Repair (MTTR) had been exceeded by weeks. On the day of the disaster, the Yellow Pod (the only one left) failed due to a dead battery. Even though the two pods did not fail simultaneously, the lack of timely repair of the blue pod made an accident inevitable.

STPA

System-Theoretic Process Analysis

A Proactive Hazard Analysis for Safety. STPA is used during the concept and design phases to “build safety in” rather than “inspecting it in” at the end. It identifies hazardous scenarios caused by complex interactions, software logic, and human-machine interfaces, even when every component is working as designed.

Advantages of STPA

More Effective: Found catastrophic design flaws in certified systems that traditional methods missed.
Faster: Completed up to 30x faster than traditional FTA or FMEA.
Higher ROI: Identifying flaws during the concept phase is orders of magnitude less expensive than late-stage fixes.

Learn more: Why Use STPA?

STPA-Sec

STPA for Security

A System-Theoretic Approach to Cybersecurity. STPA-Sec moves beyond “perimeter defense” to focus on functional vulnerabilities. It analyzes how an attacker can manipulate control loops and feedback to cause a loss, even without a technical “breach”.

Advantages of STPA-Sec

Anticipates Attacks: Successfully identified the exact vulnerabilities exploited in the SolarWinds supply chain attack months before it occurred.
Beyond Threats: Identifies hazards arising from “nominal performance”, such as sensors being blinded by environmental factors.
Comprehensive: Integrates the human operator and organizational hierarchy into the security structure.

CAST

Causal Analysis based on Systems Theory

For Advanced Accident and Incident Investigation. CAST is a structured methodology for learning from past losses or near-misses. It shifts the focus from “who to blame” to “why it made sense” for people to act the way they did, uncovering the systemic factors that allowed the event to occur.

Advantages of CAST

Identifies Latent Risk: Uncovers organizational and social factors that traditional Root Cause Analysis (RCA) overlooks.
Reduces Bias: Minimizes hindsight bias by modeling the controller’s actual process model at the time of the event.
Scalable: Reusable control structure models make subsequent investigations faster and more consistent.

Learn more: Why Use CAST?

The Paradigm Shift

Across the aviation, automotive, medical, space, and defense industries, the evidence for STAMP-based approaches is clear:

Feature	Traditional Methods (FMEA, FTA, RCA)	STAMP-Based Methods (STPA, STPA-Sec, CAST)
Causality Model	Chain of Events / Failure Propagation Failure_A -> Failure_B -> Failure_C	STAMP: Considers failures, unsafe interactions without a failure, non-linear causality, and emergent behavior Action_A -> Belief_B -> Action_C
Focus	“What failed?”	“What context made the action unsafe?” “Why would an unsafe decision appear reasonable at the time?”
Software	Hard to model software and human decision-making	Directly identifies software and human decision-making flaws
Human Error	Viewed as a “Root Cause”	Viewed as a symptom of systemic flaws in the design or organization
Cost	High: Frequent “patching” of symptoms; high risk of recurring losses or late-stage retrofits	Low: Lifecycle costs reduced by identifying flaws early, minimizing expensive rework, and preventing losses

Where to Go Next

Keep Learning

The introductions to the methods, the evidence for using them, and the industry pages are all free.

STAMP Resources

Take a Class

Self-paced online courses and live classes, with certification for those who want it.

See the classes

Get Help on a Project

We work alongside teams applying STPA or CAST to their own systems.

About project support

Questions? Email [email protected].

Mastering Complexity

Explaining the “Why”

TRADITIONAL

CAUSES

SOLUTIONS

STAMP

VIEW

SOLUTION

REAL-WORLD EXAMPLE

TRADITIONAL

CAUSE

SOLUTION

STAMP

VIEW

SOLUTION

REAL-WORLD EXAMPLE

TRADITIONAL

CAUSE

SOLUTION

STAMP

VIEW

SOLUTION

REAL-WORLD EXAMPLE

TRADITIONAL

CAUSE

SOLUTION

STAMP

VIEW

SOLUTION

REAL-WORLD EXAMPLE

STPA

Advantages of STPA

STPA-Sec

Advantages of STPA-Sec

CAST

Advantages of CAST

The Paradigm Shift

Where to Go Next

Keep Learning

Take a Class

Get Help on a Project

Stay in Touch