Confidence thresholds: when to automate, review, or not decide

A decision model gives you a number. A threshold is the rule that turns the number into an action: automate above this, ask a person below it. Choosing that rule well matters more than most model choices, and it is a business decision more than a technical one.

Five words that are not synonyms

Most confusion about thresholds comes from treating these as the same thing.

A single decision with 95% confidence is not “95% correct”. It is either right or wrong. The 95% is the model’s estimate, and it becomes useful once you know what happens, on your data, to decisions that carry that number. If decisions at 95% confidence turn out right about 95% of the time, the model is well calibrated at that level. If they are right 80% of the time, the same threshold is doing something very different from what its name suggests.

Three zones, not one line

A single cut-off forces every decision to be either automated or not. Two thresholds give you three outcomes, and the third is the one teams forget.

function disposition(support: number, policy: { automateAt: number; abstainBelow: number }) {
  if (support >= policy.automateAt) return "automate";
  if (support >= policy.abstainBelow) return "review";
  return "abstain"; // don't decide: ask for more information
}

The bottom zone exists because a low-confidence answer is not a weak suggestion; it is close to no suggestion. Showing a reviewer “Approve (52%)” anchors them on an answer the model barely preferred. It is more honest to say that the system could not decide. This is abstention, and its threshold is measured differently from the automation threshold.

Thresholds come from costs

There is no universal threshold. The right one depends on five things:

• The cost of a false positive. Acting when you shouldn’t have: approving a refund that was outside policy.
• The cost of a false negative. Not acting when you should have: denying a refund that was owed.
• Decision volume. A 2% error rate is two mistakes a week at 100 decisions a week and two hundred at 10,000.
• Risk tolerance. Some errors are embarrassing; some are regulatory.
• Operational consequences. Review has a cost too. Every decision you send to a person takes reviewer time, which is limited.

A worked example

Suppose you handle 1,000 refund requests a month. A wrongly approved refund costs you $40 on average. A wrongly denied one costs about $150, counting the chargeback risk and the support time to fix it. A human review costs $3. You have measured the following on a labeled sample (the numbers are invented for the arithmetic):

At 0.70 you automate the most and pay for it in errors: 30 × $40 + 12 × $150 + 100 × $3 = $3,300. At 0.99 you make no automated mistakes and pay $2,400 for reviewers. The cheapest point is in between, and it moves if any of the three costs changes. Double the cost of a wrong denial and the 0.95 row wins. Halve the review cost and stricter thresholds become attractive across the board.

One bar per direction

When the two mistakes cost different amounts, the two directions deserve different bars. A predicate makes this natural, because it returns a probability rather than a label.

// A predicate gives you a probability, so each direction can have its own bar.
const p = answer.probability;

if (p >= 0.9) approveRefund(request);          // act on "yes"
else if (p <= 0.03) denyRefund(request);       // act on "no": a stricter bar
else sendToReview(request, p);

Here an approval needs a probability of at least 0.90, while an automated denial needs the probability of approval to be 0.03 or lower. That reflects a wrong denial costing nearly four times as much as a wrong approval. Many teams go further and never automate the expensive direction at all.

One threshold per decision

A threshold that works for spam detection tells you nothing about refund approval. The costs differ, and so does how well the model’s confidence tracks accuracy on each task. Within one decision, you may also want different thresholds for different segments: a $20 refund and a $2,000 refund are not the same risk.

Thresholds also expire. A new product line, a policy change, or a model update can shift the relationship between confidence and accuracy. Re-check on fresh labeled examples when any of those happen, and on a schedule regardless.

How to actually set one

1. Collect a few hundred real examples and have people label the right answer.
2. Run the decision on each and record the answer and its confidence.
3. For each candidate threshold, count how many decisions would be automated and how many of those would be wrong.
4. Put your costs on those counts and pick the threshold your business can live with.

The calibration guide walks through each step, including how much data you need before the numbers mean anything.

Related

• Human-in-the-loop AI: designing the review step the middle zone feeds.
• Refund eligibility template: a decision with asymmetric costs.
• Playground: move the thresholds and watch the disposition change.