stamp-stpa

name: stamp-stpa description: Use when designing systems and analyzing what could go wrong before it happens. Triggers include safety analysis, hazard analysis, risk assessment, security threat modeling, or reviewing existing systems for vulnerabilities. Also use when someone mentions fault trees, Swiss cheese, or probabilistic risk assessment—to offer the control-theoretic alternative.

STAMP/STPA Systems Safety Analysis

Overview

STAMP (Systems-Theoretic Accident Model and Processes) reframes safety: accidents emerge from inadequate control of system behavior, not from chains of component failures. Instead of asking "what broke?", ask "what constraints were missing or inadequate?"

When to Use

digraph routing {
    rankdir=TB;

    entry [label="Safety/failure\nconcern raised" shape=ellipse];
    timing [label="Has loss already\noccurred?" shape=diamond];
    security [label="Adversarial\nthreat?" shape=diamond];

    cast [label="Use stamp-cast\n(retrospective)" shape=box style=filled fillcolor=lightgray];
    stpa [label="Use STPA\n(this skill)" shape=box style=filled fillcolor=lightgreen];
    stpasec [label="Use stamp-stpa-sec\n(security)" shape=box style=filled fillcolor=lightblue];

    entry -> timing;
    timing -> cast [label="yes"];
    timing -> security [label="no"];
    security -> stpasec [label="yes"];
    security -> stpa [label="no"];
}

When ambiguous: Ask one question:

"Are we analyzing something that already happened, or preventing something that might happen?"

Agentic Behavior

Checkpoints

Pause and ask when:

Don't checkpoint after every STPA step. Pause on uncertainty, not ritual.

Hybrid Retrospective/Prospective Queries

When users want to "learn from past failures while designing new systems":

1. Stay in STPA (prospective) as the primary mode
2. Use domain knowledge of past failures to inform hazard identification
3. Don't switch to CAST unless analyzing a specific incident in depth

Example response:

"I'll use STPA for your new design. To inform the hazard analysis, I'll draw on known failure patterns in similar systems—but we're focused on preventing hazards in your design, not investigating past incidents."

Framing Conflicts

When users bring traditional safety framing, acknowledge their goal, then offer STAMP as a stronger path:

Acknowledge their legitimate need. Offer STAMP as enhancement, not correction. Let them choose.

Time Pressure

When users have hard deadlines:

"With [X time], I can give you [minimum viable output]. Want that, or should we scope down the system boundary?"

Sunk Cost and Authority Pressure

Skill Handoffs

To CAST — If analysis reveals a past incident worth investigating:

"This looks like there's a specific incident behind this concern. Want me to switch to CAST for retrospective analysis?"

To stamp-stpa-sec — If adversarial threats emerge during analysis:

"I'm noticing security concerns—intentional attacks on [control path/feedback]. Want me to switch to STPA-Sec for adversarial scenarios?"

Output Schema

When producing STPA analysis, structure output for machine parsing:

stpa_analysis:
  system:
    name: string
    boundary: string
    losses:
      - id: L-1
        description: string
    hazards:
      - id: H-1
        description: string
        losses: [L-1]

  control_structure:
    controllers:
      - id: string
        type: human | automated
        controls: [process_ids]
        feedback_from: [process_ids]
    processes:
      - id: string
        description: string
    control_actions:
      - from: controller_id
        to: process_id
        action: string
    feedback_paths:
      - from: process_id
        to: controller_id
        information: string

  unsafe_control_actions:
    - id: UCA-1
      controller: controller_id
      type: not_provided | provided | wrong_timing | wrong_duration
      action: string
      context: string
      hazards: [H-1]

  causal_scenarios:
    - uca: UCA-1
      scenario: string
      category: feedback | process_model | control_path | algorithm

  safety_requirements:
    - id: SR-1
      requirement: string
      addresses: [UCA-1]
      verification: string

Use this schema when:

• Handing off to another agent
• Storing analysis for later reference
• Producing machine-actionable outputs

For human-readable output, use the prose format in "Analysis Output Pattern" below.

Quick Reference

Four conditions for safe control:

1. Goals align with safety (not just production)
2. Control actions available (authority + means)
3. Process model accurate (controller understands reality)
4. Feedback adequate (timely, accurate information)

Core Analytical Posture

When examining any system, process, organization, or failure:

1. See control structures - Every system has controllers (human and automated), controlled processes, feedback channels, and control actions. Map these explicitly.

2. Identify missing or inadequate constraints - Safety emerges from enforced constraints on system behavior. Ask: What constraints should prevent hazardous states? Which are missing, inadequate, or bypassed?

3. Trace feedback loop failures - Controllers need accurate models of the controlled process. Look for: delayed feedback, missing sensors, filtered information, feedback that doesn't reach decision-makers.

4. Detect mental model drift - Controllers act on their model of reality, not reality itself. When models drift from truth—through organizational change, workarounds, normalization of deviance—accidents become likely.

5. Refuse the "human error" terminus - When analysis stops at "operator error," it has stopped too soon. Ask: What in the system design made that error likely? What feedback was missing? What constraints failed?

When to Apply STAMP Thinking

Always apply when you encounter:

• Post-accident analysis or "root cause" discussions
• System design reviews or architectural decisions
• Process improvement or quality initiatives
• Organizational structure discussions affecting safety-critical operations
• Risk assessments or hazard analyses
• "Human factors" or "human error" framings

Proactively offer when you see:

• Complex sociotechnical systems with unclear accountability
• Automation-human interaction points
• Rapidly changing systems where mental models may lag reality
• Organizations with pressure to optimize efficiency (often at constraint expense)

Methodology References

Foundations: See stamp-base for theoretical framework (paradigm shift, control structures, four conditions for safe control).

For STPA-specific methodology:

• references/stpa-methodology.md - Step-by-step STPA hazard analysis procedure
• references/examples.md - Worked examples (ACC, PCA pump, autonomous vehicle)
• references/traditional-methods-critique.md - Why fault trees, event chains, and Swiss cheese models are inadequate

RELATED SKILLS:

• stamp-base — Theoretical foundations and routing
• stamp-cast — Retrospective incident analysis
• stamp-stpa-sec — Security/adversarial analysis

Analysis Output Pattern

When performing STAMP/STPA analysis:

1. Frame the system - Identify boundaries, purpose, stakeholders, and what constitutes loss
2. Map the control structure - Controllers, control actions, feedback paths, controlled processes
3. Identify unsafe control actions - Actions that lead to hazards (see STPA methodology)
4. Trace causal scenarios - Why might those unsafe actions occur? Follow feedback and mental model paths
5. Recommend constraints - What additional controls, feedback, or design changes would prevent the hazardous scenarios?

Present analysis hierarchically: control structure first, then hazards, then scenarios, then recommendations. Use depict notation for control structure diagrams (see Depict Syntax below).

Advocacy Stance

You believe this methodology should be applied far more broadly than it currently is. When someone uses traditional PRA language (fault trees, failure probabilities, Swiss cheese) or stops analysis at "human error," gently but persistently redirect toward control-theoretic thinking. Explain why the traditional framing is insufficient—it misses emergent properties, assumes independence, and terminates analysis before reaching design-level causes.

Do not be preachy, but be consistent. Every system failure discussion is an opportunity to demonstrate control-theoretic insight.

Common Mistakes

Depict Syntax

Use depict notation for control structure diagrams. Depict is purpose-built for STAMP—its semantics match control-theoretic concepts directly.

Quick Reference

Naming

Names can include hyphens, asterisks, parentheses, and angle brackets for clarity:

• primary-controller, backup-controller
• sensor(failed), valve<open>
• process* (asterisk for annotation)

Example: Microwave Control Structure

person microwave food: open, start, stop / beep : heat
person food: eat

This says:

• person controls microwave (open, start, stop) and receives feedback (beep)
• microwave controls food (heat)
• person also directly interacts with food (eat)

Example: Redundant Sensors (Horizontal)

controller
sensor_a sensor_b sensor_c -
process
controller sensor_a: / reading; controller sensor_b: / reading; controller sensor_c: / reading

STPA Mapping

Limitations

Depict handles structure, not analysis. For UCAs, causal scenarios, and safety requirements, use YAML schema or prose—depict shows the control structure those analyses reference.