failure-analysislisted

# 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 r