failure_mode_analysis v1.0.0

name: failure_mode_analysis description: Runs a premortem, maps blast radius, and defines a graceful-degradation ladder for an agent system before it ships. Triggers when asked to stress-test a plan, review what can go wrong in an agent deployment, or keep a catalog of known failure modes.

Failure Mode Analysis

Purpose

Find the ways an agent system can fail before it fails. A plan written optimistically hides its weak spots; this skill forces failure into the past tense ("it already broke, why?"), sorts what matters from what is noise, and turns the scary ones into design changes, tripwires, and fallback levels.

Use it before building anything non-trivial: a multi-agent pipeline, a tool-using agent with real actions, a scheduled loop, an agent facing users or money.

Workflow

1. Frame the plan. One sentence for the goal, one sentence for what success looks like and how it is measured. Name the horizon ("3 months after launch"). Without a frame, the analysis drifts.

1. Run the premortem. Set the failure as fact, past tense: "It is [horizon]. This failed: [rollback / data loss / nobody adopted it]. It failed. Why?" Then sweep for causes across at least four of these categories: technical, scope/effort, dependencies, ops/people, data, security/safety. Force a second pass with the question: "What did the plan most need to be true that was not?" Keep going until you have 8 or more distinct reasons. Do not rank while brainstorming; breadth first.

1. Score and triage. Score each mode on Likelihood, Impact, and Detectability (1-5 each). Rank by the product. Sort into three bins: Tiger (real threat, needs a mitigation), Paper Tiger (looks scary, evidence says probably fine), Elephant (nobody wants to talk about it, talk about it). Cut anything vague; keep only modes concrete enough that a prevention action is imaginable. For the top 3-5: restate the failed outcome in past tense, list the conditions that had to be true for it to happen, and invert each condition into a verifiable prevention requirement (avoid/require rule plus a check). Every top mode gets an owner, a verification checkpoint, and a ship gate.

1. Map the blast radius. List the agent's actions and group them by reversibility and reach: read-only, reversible and low blast radius, stateful and visible, irreversible and high blast radius. Ask: if this action goes wrong, what else breaks? Which failures cascade (a hanging dependency thread pool starves critical paths) and which stay contained? The output is a map, not a list: which components can fail without taking down the rest, where the bulkheads are, where they are missing.

1. Write the degradation ladder. Define the fallback for every significant failure mode from step 3, in levels:

• Level 0: full functionality
• Level 1: reduced quality (cached or simplified responses)
• Level 2: core only (non-AI features still work)
• Level 3: maintenance mode (system owns the failure, no functionality) Every level needs user-facing messaging: what does the user see? No silent failures. Define tripwires quantitatively: observable metric, threshold, pre-committed response. "Monitor closely" is not a tripwire.

1. Log it. Record the top modes and their mitigations in the failure catalog (see Tooling). A premortem with no plan change is incomplete: list the concrete tasks, tests, gates, or rollbacks added to the plan because of this analysis.

Output Contract

## Failure-Mode Analysis: <plan name>
**Plan:** <one sentence> | **Success looks like:** <measurable>
**Premortem frame:** <past-tense failure date and outcome>

### Top failure modes
| Mode | L | I | D | LxIxD | Bin | Mitigation | Owner | Gate |
|---|---|---|---|---|---|---|---|---|
| ... | 1-5 | 1-5 | 1-5 | product | Tiger/Paper/Elephant | concrete action | name | what blocks shipping |

### Blast-radius map
| Action / component | Tier (0-3) | If it fails, what breaks | Containment |
|---|---|---|---|

### Degradation ladder
| Level | Trigger | Behavior | User sees |
|---|---|---|---|
| 0-3 | tripwire metric + threshold | fallback | exact messaging |

### Plan changes from this analysis
- <task, test, gate, or rollback added>

Tooling

bin/failure_catalog.py keeps a JSON failure catalog per project: add a mode, score it, top lists by LxIxD, export renders the table for the output contract. Run python3 bin/failure_catalog.py --help.

Operating Rules

1. Failure is stated as fact in the past tense. "What might go wrong" is the prompt of someone predicting; "it failed, explain why" is the prompt of someone investigating. Only the second works.
2. Detectability is scored on the feedback mechanisms the plan actually has, not the ones it could have. A low-likelihood, high-impact mode you will never see coming outranks a likely, visible one.
3. Every mitigation must be executable before the plan runs, or tied to a tripwire with a metric, a threshold, and a pre-committed response. "Monitor closely" and "be careful" are not mitigations.
4. Verify before flagging. Do not call a risk a Tiger on pattern matching alone: read the surrounding context, check for existing fallbacks, confirm it is in scope. False alarms teach the team to ignore the analysis.
5. A mode that is not concrete enough to mitigate is cut, not kept. Generic dread ("the API might change") goes back into the brainstorm until it becomes a specific failure ("the provider deprecates v1 endpoints, breaking our 14 pinned calls").
6. Keep the analysis proportional: quick plans get the quick pass (steps 1-3, top 3 modes), ships that touch money, data, or other people's systems get the full ladder plus the catalog.