failure-analysis

Failure analysis

Produce a prioritized failure inventory grounded in the actual design/code, not a list of imaginable disasters. Assessment does not authorize fixes, chaos tests, live faults, deployment or data mutations.

Consequence before arithmetic

For each credible failure mode, identify:

• Trigger and affected operation, backed by a path, artifact or stated assumption.
• Impact: who/what is harmed, blast radius, reversibility and time to damage.
• Exposure/likelihood with its evidence and uncertainty. Unknown is not rare.
• Detection and containment: does intervention occur before irreversible harm?
• Recovery: tested restoration/reconciliation versus merely a proposed plan.
• Existing controls, surviving gap, next proof and owner when known.

No absolute RPN thresholds and no automatic risk acceptance. Multiplying ordinal severity/likelihood/detectability scores cannot decide release gates. A catastrophic event scored 10×1×1=10 is not acceptable just because it is rare and loud; alerting after a charge or disclosure does not undo it.

Prioritize credible uncontained irreversible harm first. Distinguish an active incident (route to containment/troubleshooting) from a prospective release risk. Block the affected release path when a credible severe failure lacks prevention, bounded containment or demonstrated recovery. State what evidence clears it. Lower-impact, recoverable degradation may be scheduled or explicitly accepted by the authorized owner with rationale and monitoring; the skill cannot accept risk for them. Controls that truly prevent the trigger may lower priority: don't manufacture a blocker from severity alone.

Dependency walk

Trace trigger → caller → storage/queue → consumer → external effect. At each edge check failure, slowness, duplication, partial completion, exhaustion and recovery. Follow all durable-write and retry boundaries, not just the happy-path handler. Examples are investigation prompts, not findings.

Allocate deadlines within the end-to-end budget, propagate cancellation, and leave time for cleanup/retries. A shorter caller deadline is not itself proof of a bug: establish whether downstream work continues and causes harm.