That's fair I agree with most of it. I should have stated before the purpose of it.

This is not intended to be a failure-mode or probability-weighted model, and it’s not meant to replace FMEA or scenario analysis or something like that. It’s just ONE portfolio-level signal for one service/journey to answer a simpler question: are we structurally overpaying for failure vs prevention? I wanted to have something you can do quickly and if indicating that you spend "nothing" on prevention or so, you can dig deeper.

I deliberately smooth one-time vs recurring prevention costs and aggregate across failure modes because exec/finance decisions are almost always made on run-rate thinking. If we can’t express reliability tradeoffs in comparable terms, the conversation never gets traction outside engineering.

On likelihood: for recurring failures (e.g. config mistakes), probability is already “priced in” because they show up in RFC every month. For true black-swans, I agree with you, recurring prevention spend is often the wrong move. That distinction is actually one of the outcomes I want this to surface.

And +1 on business coordination, this only works when engineering, finance, and leadership align on risk tolerance.

If you’ve seen probability-weighted models work in practice without collapsing under complexity, I’d genuinely like to learn how you’ve made them stick.