When a two percent error rate is a rounding error and when it ends the project

Two percent wrong. In one product that is a rounding error nobody notices. In another it is the reason the project gets shut down. The number is identical. The verdict is opposite. Whether an error rate is fine or fatal has almost nothing to do with the rate itself and almost everything to do with what one error costs when it lands.

The rate is not the risk

We keep reaching for the accuracy percentage as if it were the answer. It is only half of one. The other half is the cost of a single mistake, and until you multiply the two you do not know whether you have a problem.

An engineering leader at an e-commerce company described the comfortable side of this. Their AI feature suggested related products, and it was wrong maybe two percent of the time. A wrong suggestion cost nothing. The customer ignored it and moved on, and the other ninety-eight percent quietly drove real value. At that cost per error, they could have tolerated far more than two percent. The rate was almost irrelevant, because a mistake was close to free.

Then he described watching the same rate destroy a different feature. A tool that auto-approved expense reports at two percent wrong meant a steady stream of incorrect approvals flowing straight to the ledger, each one a real financial and audit problem. Same two percent. One feature shrugged it off. The other could not survive it. Nothing about the models differed. The cost of an error did.

When two percent ends things

The disqualifying side is worth sitting with, because it is where projects die quietly.

A CTO at a compliance-software company put it in the bluntest terms I have heard. In his domain, two percent wrong is not a quality metric. It is a regulatory exposure metric. A feature that misclassifies two percent of filings is not ninety-eight percent good. It is a source of two percent violations, and a regulator does not grade on a curve. For that use case the acceptable error rate was not two percent or one percent. It was low enough that a human had to review anything the model was not certain about, because the cost of a single miss was measured in fines and lost licenses.

His framing generalizes. Some errors are absorbed by the user for free. Some are absorbed by the business at a survivable cost. And some are not absorbed at all, because a single one is catastrophic, and for those the tolerable rate approaches zero no matter how good the model looks.

Judging an error rate honestly

To know whether your error rate is a rounding error or a project killer:

Price one error. What does a single wrong output actually cost, in money, trust, or exposure? That number decides everything.
Find the worst case, not the average. The rare expensive error can end a project even when the average looks fine.
Check who absorbs it. A mistake the user shrugs off is cheap. A mistake that hits the ledger or a regulator is not.
Set the bar from the cost. Let the cost of an error set the acceptable rate, rather than accepting whatever the model happens to deliver.

How we approach it at Density Labs

When a team asks whether their error rate is good enough, we turn the question around and ask what one error costs. We map the outputs to their consequences, find the cases where a single mistake is expensive or unrecoverable, and judge the rate against those, not against a comfortable average. Frequently a feature that looked risky is fine because its errors are cheap, and just as often a feature that looked ready is disqualified because two percent of its outputs are the kind you cannot afford at all.

An error rate on its own is a number without a verdict. Multiply it by the cost of being wrong and the verdict appears. That product, not the percentage, is what tells you whether you have a feature or a liability.