STPA Step 4 - Identify Loss Scenarios by tracing causal pathways back through control loops to understand why UCAs might occur. After completing STPA Step 3. When you need to understand WHY unsafe control actions might happen. When developing recommendations and mitigations.
For each Unsafe Control Action (UCA) identified in Step 3:
"I'm using the STPA Step 4 skill to identify loss scenarios. We'll trace each UCA back through the control structure to understand what could cause it."
The controller issues an unsafe control action because of:
Even if the correct control action is issued:
For each UCA, consider these causal categories:
Unsafe control algorithm
Incorrect process model
Inadequate feedback
Control action not executed
Feedback not provided
Step A: State the UCA
UCA-X: [Controller] [action context] leading to [H-X]
Step B: Ask "Why might this happen?"
Walk backward through the control loop:
Why might the controller issue this UCA?
Why might the controller have wrong information?
Why might the action not execute correctly?
Step C: Document each causal pathway
### UCA-X: [description]
**Scenario 1: [Brief name]**
[Controller] [reason for issuing UCA] because [root cause].
The controller's process model was incorrect because [specific gap].
**Recommendation:** [Mitigation measure]
**Scenario 2: [Brief name]**
Even though correct command was issued, [reason execution failed] because [root cause].
**Recommendation:** [Mitigation measure]
Scenario 1: Credential Check Bypassed Auth Service issues token without proper verification because the validation logic contains a short-circuit that skips checks under high load conditions. The controller's algorithm prioritizes availability over security.
Recommendation: Remove short-circuit logic; ensure all credential validation is mandatory regardless of load. Add circuit breaker that fails closed (denies access) rather than fails open.
Scenario 2: Cached Valid Status Auth Service issues token because it uses a cached "valid" status from a previous request, not realizing the credentials were revoked. The process model is stale.
Recommendation: Implement cache invalidation on credential revocation. Add freshness checks before using cached authentication status.
Scenario 3: Response Confusion Auth Service issues token because response from identity provider was corrupted in transit and misinterpreted as "valid". Communication path has no integrity checking.
Recommendation: Add checksum/signature verification on all identity provider responses. Implement retry with fresh request on verification failure.
For each UCA, work through:
Q1: What must be true in the controller's model for this UCA to happen? (Identify the incorrect belief or assumption)
Q2: How could the controller's model become incorrect?
Q3: What could prevent proper execution of the correct action?
Q4: What would prevent/detect each scenario? (These become your recommendations)
Record in .sgai/PROJECT_MANAGEMENT.md:
### Step 4: Loss Scenarios
#### UCA-1: [description]
**Scenario 1: [Name]**
[Controller] [behavior] because [cause].
The [aspect] was [incorrect/missing/delayed] because [root cause].
**Recommendation:** [Mitigation]
**Scenario 2: [Name]**
[Description of causal pathway]
**Recommendation:** [Mitigation]
---
#### UCA-2: [description]
[Repeat for each high-priority UCA]
---
### Recommendation Summary
| ID | Recommendation | Addresses | Priority |
|----|---------------|-----------|----------|
| R-1 | [recommendation] | UCA-1, UCA-3 | High |
| R-2 | [recommendation] | UCA-2 | Medium |
When all scenarios are documented:
## STPA Findings
- [X] STPA analysis completed on [date]
- Key hazards identified: [count]
- Unsafe control actions found: [count]
- Loss scenarios analyzed: [count]
- Critical recommendations:
- R-1: [brief description]
- R-2: [brief description]
Update .sgai/PROJECT_MANAGEMENT.md with complete analysis
Set status: "agent-done" to return control
STPA is iterative. If during Step 4 you discover:
Document any iterations and the insights that triggered them.