Error tolerance is a scoping input, not an afterthought

A data science lead at a regional bank told me about the moment she stopped treating accuracy as an outcome and started treating it as an input. For years, her teams built a model, measured how often it was right, and then argued about whether that number was good enough to ship. The argument always came late, always got political, and always happened after the expensive part was done.

She flipped it. Now, before anyone builds anything, she makes the business owner answer two questions. What error rate can you live with? And which kind of error hurts more?

Those two answers, written down in discovery, change everything that comes after.

The two questions are not the same

People collapse error into a single number, but a model has at least two ways to be wrong, and they rarely cost the same. In her world the split is obvious. A model that flags a legitimate transaction as fraud annoys a good customer and ties up a support agent. A model that misses real fraud lets money walk out the door. Same overall accuracy, completely different pain.

If you do not name which error you fear, the model quietly picks for you. Every classifier sits on a dial between catching too much and missing too much, and where you set that dial is a business decision, not a technical one. She learned to make the business owner turn the dial in the meeting, in plain language. “I would rather bother ten good customers than miss one real fraud” is a scoping decision. It sets the threshold, and the threshold changes what “done” looks like.

The acceptable rate matters just as much. AI features usually need to clear about 85 percent accuracy before their mistakes stop compounding into something worse than the manual process, but that is a floor, not an answer. For a first-pass filter that a human reviews, sixty percent might be a real help. For a step that acts on its own, ninety-five might still be too low. You cannot know until someone tells you what a wrong answer does downstream.

What changes when you decide it early

Once she gets those two answers, the design almost writes itself. She gave me the shape of it.

The acceptable error rate tells you whether you need a human in the loop or can let the model act alone.
The costly error type tells you which way to tune, and which mistakes to hunt for in testing.
Together they tell you how much data, how much review, and how much monitoring the thing actually needs.

Decide all of that at the end and you have usually built the wrong thing. She watched a neighboring team spend months on a model tuned for overall accuracy, only to learn at the review that the business would trade a lot of accuracy to almost never miss the costly case. They rebuilt it. The information they needed existed on day one. Nobody asked for it.

A friend who leads risk at an insurer told me the same story from a different seat. Her rule is that no model project starts without a one-line error budget signed by the person who owns the outcome, not the person building the model. When the builder owns the error target, it drifts toward what is easy to hit. When the business owns it, it reflects what the mistake actually costs.

How we approach it at Density Labs

In the AI Opportunity Assessment, our fixed two-week engagement at $2,500, we treat error tolerance as a required input, the same as data access or latency. We ask the owner to name the acceptable rate and the error they fear most, in words, before we scope a design. That single conversation often reveals that the feature needs a review step nobody budgeted for, or that it is safer and cheaper than the team assumed. Either way, you learn it while it is still cheap to change.

Do not build the model and then discover how good it has to be. Decide what wrong you can live with first, and let that decision shape everything else.