The model is 95% accurate. Should it make the decision?

During a project meeting, someone says: “The model is 95% accurate, so we can automate the decision.” It sounds like evidence of product readiness. In fact, we still do not know what was counted, which errors occurred, or what happens to a device, person or process after a wrong answer. The number alone cannot establish whether automation should accept a product, stop a line or merely advise an operator.

Consider a quality-inspection system that assigns each unit a score associated with a suspected defect. The model has already been trained. We will leave its weights unchanged and alter the rule that converts its output into action. This is an often overlooked step between evaluating an algorithm and commissioning an operational process.

Our example uses 1,000 explicitly synthetic observations, two sets of cost assumptions and limited manual-inspection capacity. These are not benchmark results or measurements from a BBest24 deployment. The aim is to identify the questions that must precede threshold selection and test whether an apparently favourable choice remains useful when conditions change.

Name the action and the error first

We define the positive class as a defective product, with higher model scores indicating stronger suspicion of a defect. A positive action holds the unit or sends it for additional handling. This definition matters more than the words positive and negative, which may have the opposite operational meaning in another project.

A false negative lets a defect pass; a false positive holds a good unit. The former may lead to a complaint, the latter to extra work or lost throughput. Their costs need not be similar. A true positive can also cost money: the defective unit must be separated, inspected or repaired. We will initially use a simplified cost function for errors and then examine its limitations.

At a minimum, detection assessment requires counts of missed defects and false alarms. Recall is the fraction of all defects detected; precision is the fraction of alarms that correspond to actual defects. The scikit-learn 1.9.1 documentation gives the definitions and denominators. A report should put counts beside percentages. A recall of 90% based on ten defects has different evidential strength from the same fraction based on a thousand independent defects.

Define the unit of decision too. Ten photographs of one product do not constitute ten independent products. If an alarm stops an entire batch, its cost is not the cost of a single frame. Before optimizing a threshold, establish which operational object the procedure acts on.

Model, score and threshold are different things

A model returns a number. A decision rule might hold the unit when score ≥ t. Threshold t is a parameter of the decision, not an immutable property of the model. Two processes using identical predictions may reasonably choose different values.

Not every output between zero and one is a reliable probability. A score can rank examples well while overstating confidence. In our dataset, 0.1, 0.3, 0.5, 0.7 and 0.9 are simply points on a ranking scale. We do not interpret 0.9 as a 90% probability of a defect. This boundary lets us examine threshold selection without pretending that calibration has been performed.

Scikit-learn’s threshold-selection documentation separates model estimation from decision-making and warns against tuning the threshold on training data. In practice, use held-out data for tuning and an independent final evaluation. Repeatedly inspecting the test set while adjusting rules gradually turns it into design data.

A library’s default threshold is convenient for checking that code runs. It is not a business justification or evidence that a quality requirement is met. Similarly, a strong aggregate metric does not specify what to do when the system cannot resolve a case.

This separation also affects versioning. Keeping the same model file while changing the threshold changes product behaviour. Treating it as a minor configuration edit can bypass the review that would have been required for a new model, even when the operational impact is greater.

A dataset that can be checked by hand

Our dataset contains 950 good units and 50 defective ones. We place their scores into five groups. This deliberately small tabular model makes every calculation reproducible without training a neural network.

An automatic rule that passes everything achieves 95% accuracy because it correctly treats 950 good products. It also misses every one of the 50 defects. There is no paradox: accuracy answers a question about the fraction of correct labels, not whether this process can intercept defects.

At threshold 0.4, the 0.5, 0.7 and 0.9 groups are held. We detect 45 defects, miss five and raise 50 false alarms. Recall is 90%, precision approximately 47.4%, and accuracy 94.5%. Although accuracy is lower than the pass-everything baseline, the system now performs a function that the baseline never provided.

At threshold 0.6, false alarms fall to 15, but missed defects rise to 15. Accuracy increases to 97%, while recall falls to 70%. Is that an improvement? Without consequences for both types of error, there is no single answer. A performance plot should inform a product decision rather than substitute for one.

The table also reveals why a confusion matrix belongs beside a headline score. It lets a reviewer ask which cells changed and whether that change matches the intended purpose. An apparently small increase in accuracy may represent a large reduction in the fraction of defects intercepted.

Two processes, identical predictions

For process A, assume a missed defect costs PLN 100 and a false alarm costs PLN 2. For process B, the corresponding costs are PLN 10 and PLN 15. These are hypothetical teaching values, not service prices or an assessment of a real product’s risk. The second process can represent a situation where unnecessary interruption is expensive and a missed defect has limited consequences.

We calculate K = FN × missed-defect cost + FP × false-alarm cost. For now, we exclude fixed model-running costs and the handling of correctly detected defects. Every comparison concerns the same batch of 1,000 units.

Among the four evaluated values, process A selects 0.2 and process B selects 0.8. We changed neither the model nor the data; we changed the consequences of acting. This does not establish a global optimum over every possible threshold and cost structure. It compares explicitly defined alternatives.

For process B, the PLN 30 difference between thresholds 0.6 and 0.8 is small relative to uncertainty in the assumptions. If the missed-defect cost rises from PLN 10 to PLN 13, threshold 0.6 costs PLN 420, while threshold 0.8 costs PLN 435. The preference reverses. A team should therefore establish plausible cost ranges and test sensitivity rather than treating the smallest table entry as an objective command.

An operational constraint can reverse the decision again. If the process cannot tolerate 30 missed defects per thousand, the apparent cost winner is infeasible. It is useful to mark infeasible alternatives before ranking the remainder so that a chart cannot quietly trade away a requirement.

When the cost function is too simple

The linear model assumes that errors add independently. A real process may have thresholds: one false alarm is easy to handle, but the tenth in a minute stops production. One missed defect may trigger inspection of an entire batch. Cost then depends on timing, grouping and process state, not just label counts.

Some requirements belong as constraints rather than quantities freely exchanged for money. If the product has a maximum permitted missed-defect rate for a particular defect type, first check that condition, then compare costs among feasible alternatives. A lower objective-function value must not conceal a failed requirement.

Distinguish known costs from assumptions. Additional inspection time can be measured. Future complaint cost may come from a different product’s history. Losing a customer may be a broad scenario rather than a reliable average. An assumptions table should show each value’s source and range. That moves discussion towards premises that can be improved instead of an argument over the one supposedly correct metric.

It may also be necessary to separate defect severities. Averaging a frequent cosmetic defect with a rare but consequential functional defect can produce an attractive aggregate result while leaving the important failure mode poorly controlled. Our binary example deliberately does not establish such a policy; a real acceptance specification must decide whether different defect classes need different constraints.

A third decision: obtain more information

Instead of one threshold, define two. Scores below the lower threshold pass automatically; scores at or above the upper threshold are held automatically; scores between them go to manual inspection. The lower boundary belongs to the manual interval and the upper boundary to automatic holding. Code and tests must specify such details, particularly when scores are rounded.

With interval [0.4, 0.6), the score-0.5 group goes to a person: 45 units. Outside that group, five defective units still pass automatically and 15 good units are automatically held. Expanding the interval to [0.2, 0.8) sends 175 units to inspection, leaving two automatic misses and three automatic false alarms.

This comparison does not assume an infallible human. It identifies which cases the automated rule hands to another procedure. Final quality depends on the method, time, instructions and information available to the operator. If the operator simply confirms the model’s visible suggestion, the review is not independent. Acceptance testing should assess the accuracy and duration of this path separately.

Deferral needs an operational meaning. “Needs review” must specify an owner, deadline, storage or containment of the unit, and a completion condition. Otherwise, the system converts a classification problem into an unowned queue. Some products require stopping when no answer is available; others permit a controlled fallback. The choice follows from the application requirements.

The review outcome must return to the system with the same unit identifier. A correct human judgment attached to the wrong product is still a process error. This becomes especially important when several operators work on a shared queue or a device is inspected again after rework.

Operators have finite capacity too

Assume incoming production of 1,000 units per hour and manual-inspection capacity of 120 units per hour. The narrow interval sends 45 units per hour; the wider interval sends 175. The first fits within average capacity. The second grows the queue by 55 units each hour if conditions remain unchanged.

Even an average of 45 does not guarantee a short wait. During a sixfold input burst lasting ten minutes, the narrow policy sends 45 cases while the inspection station can process 20. The queue grows by 25. After normal input resumes, spare capacity is 75 units per hour, so draining that additional queue takes 20 minutes in this simplified fluid model.

The calculation assumes a constant difficult-case fraction, uniform service and no interruptions. A problematic production batch may increase both arrival rate and inspection difficulty. Examine service-time distributions, clustered events and maximum acceptable waiting time. Comparing averages can reveal overload, but is not a complete queueing model.

Automatically widening or narrowing the uncertainty region under overload changes the quality policy. If the system does this, the rule needs explicit design and testing. Quietly passing cases because an operator is busy is not a minor optimization detail.

A useful overload test therefore checks the disposition of physical products as well as queue length. It asks where units wait, whether they can accidentally rejoin accepted stock, and whether the system can reconstruct their status after a restart. These are consequences of the decision policy, not optional interface polish.

Calibration answers a different question

A well-calibrated probabilistic output allows declared probability to be compared with observed frequency among similar cases. It does not provide certainty about one individual unit. The scikit-learn calibration documentation explains that distinction and reliability diagrams. Our synthetic ranking scale does not satisfy this assumption, so we do not insert its values directly into an expected per-unit cost formula.

Guo and colleagues showed, for their studied networks and datasets, that strong classification performance can coexist with poor calibration, and that a simple score transformation can improve it. This is a result from a particular study, not a promise that temperature scaling repairs every model. On Calibration of Modern Neural Networks, 2017.

Before using probabilities in decisions, evaluate calibration on application-relevant data, including important subgroups. A good aggregate result may conceal weak behaviour on a new product revision. Changes in the model, preprocessing or input conditions should trigger reassessment rather than merely replacing the weights file.

Calibration and threshold selection should therefore have separate evidence. A useful ranking may support an empirically tested threshold even when its numerical scores are not trustworthy probabilities. Conversely, calibrated probabilities do not guarantee that an operationally chosen threshold satisfies the process’s capacity or quality constraints.

How will you discover the defects that passed?

If labels are collected only for held products, observation concentrates on the region where the model already suspects a problem. Misses among automatically accepted units remain unknown. The absence of a complaint is not automatically a “good product” label: a fault may emerge later or never be reported.

An observation plan should include independent checks of some accepted units and links between later information and the original decision. Sampling must support interpretation. Deliberately seeking difficult cases helps diagnosis, but without appropriate weighting it does not directly estimate error frequency across the whole production stream.

Record the model version, unrounded score, threshold version, product identifier, time and eventual assessment. Recording why a label is unavailable is useful too. These records help distinguish algorithmic improvement from a change in which products were checked at all.

Reference labels can be uncertain. If two inspectors disagree about a borderline scratch, calling one opinion ground truth does not remove the problem. Define the defect, establish a disagreement procedure, and retain the fact that some cases remain unresolved. Collapsing every disagreement into a convenient binary label can make evaluation appear more decisive than the underlying evidence.

A change in defect frequency changes the process result

Our example contains 5% defective units. An evaluation dataset may deliberately contain more defects than routine production to make rare cases easier to study. Its alarm rate and precision cannot be transferred directly to the factory without adjustment.

Keeping sensitivity at 90% and the false-positive rate at 50/950, a defect prevalence of 1% gives approximately nine true alarms and 52.1 false alarms per thousand units in expectation. Precision falls to approximately 14.7%. This calculation assumes unchanged class-conditional model behaviour; a real production change may violate that assumption too.

The conclusion is not automatically that the model deteriorated. Conditions for interpreting its output changed. Determine whether the shift concerns class frequency, product appearance, image quality or the definition of a defect. These changes may require different responses. Automatically adjusting a threshold without labels can hide a camera problem that no threshold will repair.

Monitoring should preserve the distinctions needed for that investigation. Tracking only the aggregate alarm rate cannot tell whether production improved, lighting changed or the model stopped seeing defects. A smaller set of interpretable signals, paired with independent checks, is more useful than a large dashboard without a diagnostic hypothesis.

An invalid result is not a negative result

A threshold rule assumes the model received valid input and returned a valid number. An empty frame, timeout, incompatible image size or NaN needs a separate path. Code that substitutes zero after an error and interprets zero as “no defect” is particularly dangerous: a technical failure becomes systematic automatic acceptance.

A contract should precede thresholding: input completeness, compatible versions, permitted output range and prediction freshness for the specific unit. A prediction delayed by one product may be mathematically correct and operationally useless. Identifier association matters as much as score value.

Inject these conditions during acceptance testing and check final behaviour. An “inference error” log helps diagnosis, but does not establish whether the product was held. The process owner must define the permitted response, and implementation must demonstrate it through an observable state.

Accept the decision policy as a complete workflow

Acceptance concerns the complete flow, not just the model file. Freeze preprocessing, model, thresholds and manual-inspection instructions. Use held-out data to check overall results and relevant product groups, then test arrival patterns, overload and missing feedback.

A minimum decision record contains:

• the defect definition, decision unit and source of reference labels;
• lower and upper thresholds, including equality at each boundary;
• missed defects, false alarms and deferrals with their denominators;
• cost assumptions, quality constraints and sensitivity of the choice;
• manual capacity, waiting limits and overload behaviour;
• rollback criteria and a way to recover the previous configuration.

Before full automation, a shadow evaluation can propose actions while the existing process still makes the decisions. This is useful only if disagreements and actual outcomes are recorded. Running for a week without a software crash does not demonstrate correct decision-making.

A threshold is part of the product. It needs an owner, version, rationale and conditions for reassessment. Only then can a model-accuracy claim become something more useful: we know which decisions the system makes, which errors it permits, how we observe them and what happens when operating conditions no longer match the assumptions.

Sources

• scikit-learn 1.9.1: Tuning the decision threshold for class prediction - separating prediction from action and using separate threshold-tuning data.
• scikit-learn 1.9.1: Metrics and scoring - classification metric definitions.
• scikit-learn 1.9.1: Probability calibration - probability interpretation and calibration assessment.
• Guo, Pleiss, Sun, Weinberger: On Calibration of Modern Neural Networks, ICML 2017 - research on neural-network calibration.

Sources checked on 21 October 2026; the documentation identified version 1.9.1. All datasets, costs and queue calculations are synthetic examples. No real model was trained or benchmarked for this article.