// Make the bad state impossible · lesson 02

The 99% problem

Here's the number that should govern where you let a model make decisions. A system that's right ninety-nine percent of the time sounds excellent, and for a lot of work it is. But run it enough times and the one percent is not a possibility, it's a schedule. Ninety-nine percent right means one in a hundred wrong, which means across a thousand runs you will be wrong ten times, guaranteed, and you don't get to choose which ten.

This is where the mechanics from the foundations track stop being trivia and start being a design constraint. A model's output is probabilistic, and probability compounds across runs the same way it compounds across tokens. For work where a wrong answer is merely unfortunate, a draft that needs another pass, a suggestion you can ignore, ninety-nine percent is a gift. For work where a wrong answer is unacceptable, a wrong price in front of a customer, a payment to the wrong account, a record exposed to the wrong user, ninety-nine percent is not a safety margin. It's a countdown to the incident that ends the relationship.

Why doesn't "very reliable" solve the problem?

Because reliability and guarantee are different categories, and you can't buy your way from one to the other with more nines. Push the model to ninety-nine point nine and you've just moved the incident from every hundred runs to every thousand, which feels safer and is exactly as doomed on a long enough timeline. The failure isn't a bug you can drive to zero. It's a property of using a probabilistic process for a job that requires certainty. No amount of "usually right" adds up to "never wrong," and never-wrong is precisely what some requirements demand.

What the number tells you to do

Sort your requirements by whether a single failure is acceptable or catastrophic, and route them differently. The acceptable-failure work can live with the model's probability, because the occasional miss is a shrug and a redo. The catastrophic-failure work has to come out of the probabilistic path entirely and into something deterministic, something that does the same correct thing every single time, because that's the only thing that turns "usually" into "always." The rest of this track is how you build that structural certainty around the small, critical core that can't tolerate the one percent.

The takeaway: ninety-nine percent right is a countdown, not a margin, because probability compounds across runs, so anything where a single failure is catastrophic has to leave the probabilistic path for a deterministic one.