When Is a Model Good Enough to Ship? Beyond Accuracy

Why accuracy is the wrong finish line

I have seen a lot of projects treat 'accuracy above some round number' as the definition of done. Ninety per cent accuracy sounds impressive until you ask what the other ten per cent costs you. A single scalar collapses every kind of mistake into one bucket, and in most real systems mistakes are not interchangeable. A false alarm that wastes a reviewer's five minutes and a missed case that lets a fraudulent transaction through are not the same error, yet accuracy treats them identically.

Consider a churn prediction model evaluated on a dataset where twelve per cent of customers actually leave. A model that simply predicts 'stays' for everyone achieves eighty-eight per cent accuracy without learning anything. That is an extreme case, but the same distortion shows up more subtly whenever classes are imbalanced, which is most of the time in fraud detection, medical screening, defect detection, and churn. The headline number can rise while the model becomes less useful for the decision it was built to support.

The fix is not a different single metric, it is a different question. Instead of asking 'is this model accurate enough', I ask 'what happens on each side of the decision boundary, and can the business or the users tolerate that'. That reframing forces you to define thresholds tied to consequences rather than to statistical convenience, and it is the difference between a model that looks good in a notebook and one that survives contact with production traffic.

Cost-weighted thresholds: a worked example

Suppose we are screening insurance claims for potential fraud. Out of ten thousand claims, three hundred are genuinely fraudulent, a five per cent floor once you account for related noise. Investigating a flagged claim costs the company forty pounds in analyst time. Missing a fraudulent claim costs, on average, six hundred pounds in payout. These numbers are illustrative, but the shape of the trade-off is realistic and it changes everything about what threshold makes sense.

If we set the classification threshold high, we flag very few claims, catching only the most obvious fraud but missing many others. If we set it low, we flag almost everything, catching nearly all fraud but burying analysts in false positives. Accuracy alone cannot tell you where to sit on that curve because it does not know that a missed fraud costs fifteen times more than an unnecessary investigation. What you actually want is the threshold that minimises total expected cost: false positives times forty pounds, plus false negatives times six hundred pounds, summed over the whole claim volume.

Walking through it: at a threshold that yields two hundred false positives and ninety false negatives, the cost is roughly two hundred times forty, eight thousand pounds, plus ninety times six hundred, fifty four thousand pounds, for a total of sixty two thousand pounds. Nudge the threshold down so false positives rise to five hundred but false negatives drop to forty, and the cost becomes twenty thousand pounds plus twenty four thousand pounds, forty four thousand pounds total, a clear improvement even though more claims are being flagged. This is the calculation accuracy never performs, because accuracy does not know that these two error types have different prices.

The practical habit worth building is to write down the cost of each error type before you look at any model output. If you cannot state a number, even a rough one, you are choosing a threshold by instinct and calling it a metric. Once the costs are explicit, you can sweep the threshold, plot expected cost against it, and pick the minimum, or better, present the curve to whoever owns the business decision so the threshold reflects their risk appetite rather than yours.

Calibration, subgroups, and the questions accuracy cannot answer

A second threshold worth checking before shipping is calibration: when the model says there is a seventy per cent chance of an event, does that event actually happen roughly seventy per cent of the time across many such predictions? A model can be reasonably accurate at a fixed decision point while being badly calibrated, which matters enormously if anyone downstream treats the score as a probability, for instance when ranking claims by urgency or setting a risk-based price. I check this with a reliability diagram, bucketing predictions by score and comparing predicted rate to observed rate in each bucket, and I set a threshold for acceptable calibration error, not just for accuracy.

A third check is performance across subgroups rather than performance averaged over everyone. A model with ninety two per cent overall accuracy might be sitting at ninety seven per cent for the majority group in the training data and seventy eight per cent for a minority group that is underrepresented. The overall number hides that gap completely, and if the underperforming group happens to be the one where errors are most costly or most scrutinised, shipping on the overall number alone is a genuine risk. My practice is to define a minimum acceptable performance per subgroup, not just an average, and refuse to ship if any group falls below it, treating that as a hard threshold rather than a nice-to-have.

None of this works, of course, if the evaluation itself is compromised. Leakage between training and test data, whether through duplicated records, features that encode the label indirectly, or a temporal split that lets future information leak backwards, will inflate every metric discussed here, cost-weighted or not. Before I trust any threshold, I check that the split respects time where time matters, that no identifier links rows across the split, and that the test set was genuinely untouched during model selection. A threshold built on a leaking evaluation is not a threshold at all, it is a number that will fail quietly the moment real data arrives.

The practical takeaway

Shipping readiness is not a single gate, it is a small set of thresholds, each answering a distinct question: what does each type of error cost, is the model's confidence trustworthy, does performance hold up across the groups that matter, and was the evaluation clean enough to believe. Accuracy can still be one input into that picture, but it should never be the only one, and it should certainly never be the first thing you optimise before the cost structure is written down.

Before your next launch decision, try writing three numbers on a whiteboard: the cost of a false positive, the cost of a false negative, and the minimum acceptable performance for your most vulnerable subgroup. If your model clears all three under a leakage-checked evaluation, you have a genuine case for shipping. If it cannot, no accuracy figure, however impressive, should change that answer.