A classification threshold is the cut-off that turns a model’s continuous score into a decision: above it the part is flagged as defective, below it the part passes. In scikit-learn that cut-off is hard-coded: positive when the predicted probability exceeds 0.5, or the decision score exceeds 0. The default is a poor choice when one kind of wrong classification costs more than the other, or when the classes are imbalanced. A threshold is defensible when you can show the method behind it: price both errors, check whether the scores can be read as probabilities, choose the operating point on data the model never trained on, write the reasoning down, and agree in advance what forces a re-tune.
Why is the default 0.5 threshold rarely right for defect detection?
Standard learning algorithms are built to maximise accuracy, and in the two-class case that means they implicitly decide at a probability of 0.5. Accuracy treats every error as equally bad. On an inspection line that is almost never true: an escaped crack that reaches a customer and a good bracket sent to scrap are different events with different prices.
Elkan (2001) puts the core idea plainly: under unequal costs it can be optimal to act as if one class is true even when the other is more probable. The scikit-learn documentation makes the same point with a tumour-detection example, where the cost of a miss justifies flagging patients at probabilities far below 0.5. In its insurance example, the tuned classifier flags the class of interest at a probability of around 0.02 rather than 0.5.
Class imbalance makes it worse. Google’s Machine Learning Crash Course notes that when one class is rare, labelling everything the model rates at least 50% likely as positive gives undesirable results.
Choosing a classification threshold in machine learning by pricing each error
The defensible way to set a defect threshold is to pick the cut-off that minimises the expected cost of the two errors, using the probabilities the model assigns and the cost you attach to each mistake. Elkan recommends training the classifier on the data as given and then computing the cost-optimal decision explicitly from its probability estimates, rather than rebalancing the training set so that 0.5 happens to land in the right place.
The cost-ratio rule, worked once
Silva Filho et al.’s survey of classifier calibration gives the Bayes-optimal rule directly: for a calibrated classifier the threshold follows from the ratio of the two error costs. In their example, if false positives cost four times as much as false negatives, the threshold is 4 / (4 + 1) = 0.8, so the model only predicts positive when it is quite sure. Now reverse the asymmetry for an inspection line.
The rule holds only under a condition that is easy to forget. Using the cost-optimal threshold requires calibrated probability estimates, not scores that merely rank the parts. The scikit-learn cost-sensitive example says the same: given a calibrated model and a representative, large enough dataset, the threshold can be set from the cost ratio without tuning.
Is a Youden-index cutoff good enough, or do you need a cost-weighted operating point?
The Youden index, first proposed by Youden in 1950, picks the point on the ROC curve that maximises sensitivity plus specificity minus one, and in its unweighted form it treats false positives and false negatives as equally serious. The other common ROC choice, the point closest to the top-left corner, can disagree with it: Perkins and Schisterman show the two criteria pick the same cutpoint in some situations and different ones in others, and that Youden’s J is the only one that is optimal for a given weighting of misclassification rates.
That gives a usable rule. A Youden cutoff is a reasonable starting point when you genuinely cannot price the errors differently; once escapes cost visibly more than scrap, the cost-weighted operating point is the one to defend. Either way, a ranking metric does not give you an operating point: a 2026 study on industrial anomaly detection points out that the threshold, its false-positive rate and the defect recall at that threshold cannot be recovered from AUROC alone. Our article on where cost-weighted ROC analysis applies and where independent validation protocols take over covers the benchmark side of that choice.
Do you need to calibrate probabilities (Platt scaling or isotonic regression) before setting the threshold?
You need calibration if you want to derive the threshold from the cost ratio, and you can skip it if you tune the threshold empirically against the cost, at a price. Silva Filho et al. note that a well-calibrated binary classifier can simply be thresholded to minimise expected cost, while for a poorly calibrated one the optimal threshold cannot be found without optimisation. Empirical tuning, however, has to be repeated every time the cost ratio or the defect rate changes, whereas calibrating once lets you adapt all decision rules to a new skew. On a line where scrap costs and defect mix move, calibrating first is usually worth it.
Choosing between the two classic calibrators comes down to data volume and the shape of the distortion:
| Method | What it fits | Works best when | Watch for |
|---|---|---|---|
| Platt scaling (sigmoid) | A logistic curve on the raw scores | Calibration data is small and the distortion is sigmoid-shaped, as with SVMs and boosted trees | Assumes symmetric errors, a problem under heavy imbalance; cannot correct overconfidence |
| Isotonic regression | Any monotonic step function | There is enough data, roughly 1,000 samples or more per scikit-learn | Overfits on small sets; jagged curve, many scores mapped to one value |
| Temperature scaling | A single scaling parameter on the logits | Modern deep classifiers, where it has become the standard recalibration | Leaves accuracy unchanged by design |
The finding that neural networks need little calibration dates from 2005; a 2024 study of deep-learning inspection systems attributes a lack of calibration in confidence outputs to network complexity and accuracy-focused training. For deep defect classifiers we would treat the older result as historical and check the reliability diagram rather than assume.
Rare defects add one more trap. If the training set was undersampled to balance it, a 2024 analysis shows standard Platt scaling cannot properly calibrate even a perfect base model, and fitting it on the logit of the model’s predictions largely fixes the problem. Whatever method you use, fit the calibrator on data independent of the training set, or it maps probabilities closer to 0 and 1 than it should. To diagnose the result, a reliability diagram bins predictions, plots the mean predicted value against the observed fraction of positives, and a calibrated model falls near the diagonal.
Separating real defects from environmental noise when labelled data is limited
One answer to a threshold that rejects good product because it looks slightly different, yet still catches real voids, is to treat defect classes separately rather than tune one global number. An inspection-calibration checklist from iFactory recommends a threshold per defect class: lower thresholds for critical classes that carry safety or major customer risk, higher thresholds for cosmetic classes where false-positive control matters more. The same checklist argues that a single global threshold is suboptimal for critical and minor classes at the same time. Applied to escapes and false rejects, that means moving the critical-class threshold down and the cosmetic-class threshold up, rather than moving everything together.
With only a few months of production history, be honest about what the threshold rests on. The US Federal Reserve’s SR 11-7 guidance on model risk says that where validation is limited by data paucity, that fact should be documented, communicated, and offset by compensating controls. Its point carries over to a young inspection line: write down that the threshold was set on six months of data, schedule its review, and keep a human check on borderline rejects until the history grows. For anomaly detectors trained on normal parts only, the Anomalib documentation warns that a validation set without anomalous samples sets the threshold at the highest normal score observed, which is fragile.
Whether a calibrated threshold survives a lighting or optics change is not something to assume: it needs a before-and-after check on a fixed reference set, and that procedure gets its own section further on.
A statistical gate that tells sampling noise from real miscalibration
On a finite validation set, an apparent calibration gap may be an artefact of random noise. Lee, Huang, Hassani and Dobriban (2022) frame calibration checking as a hypothesis test, with “the model is calibrated” as the null, and propose T-Cal, a minimax-optimal test based on a debiased estimate of the expected calibration error. They also show that detecting miscalibration is only possible when the class probabilities vary smoothly with the predictions. For scoring probabilistic outputs, log-loss is a proper scoring rule and the loss most calibration methods use.
Offline numbers are themselves uncertain. The scikit-learn documentation warns that a business metric estimated by cross-validation becomes unreliable when the minority class is very small, and that offline estimates should ideally be confirmed on live data. Any gate also needs enough independent samples: a false-positive claim at a given confidence requires a minimum number of independent normal units.
Loosening a threshold without looking like you are hiding defects
A threshold change, in either direction, holds up when it traces back to written cost assumptions and a trigger agreed before the change, not to a bad week of false rejects. TechnoLynx’s production AI reliability work covers this with quality teams: pinning down which decision is being defended (one threshold value, or the rules for re-tuning it), choosing a cost-weighted method and the statistical criteria for a meaningful score shift, implementing both beside the existing AOI pipeline, back-testing against historical defect data, and putting the re-validation procedure and its sign-off roles into the production quality workflow.
Loosening a threshold to cut false rejects has a real argument behind it, and it is worth making explicitly. The iFactory checklist puts the false-positive rate at which operators start distrusting and bypassing an AI vision system at three to five percent of inspections. A system operators override catches nothing, so excessive false rejects are a quality risk as well as a cost. The justification file should show the trade-off you accepted: how much escape risk you took on for how much false-reject reduction, under which cost assumptions, and who agreed those assumptions with the customer.
Be careful with claims about what a quality standard demands. Micro Precision, a calibration provider, notes that IATF 16949 customer-specific requirements may add their own requirements for measurement-system studies. We would treat a threshold change as a change to the measurement system and confirm the re-approval trigger against the contract or QMS clause that actually applies. SR 11-7 offers a useful pattern from another regulated field: validation should set thresholds for acceptable error and continue on an ongoing basis after the model goes into use.
Writing down what counts as a score shift, and who signs off
Without a formal definition, a score shift caused by a new supplier or mill looks just like day-to-day noise, and any re-tune made in response is hard to defend afterwards. One 2026 study of deployment reliability measured drift with Kolmogorov–Smirnov statistics for numeric inputs and Jensen–Shannon divergence for categorical ones, aggregated into a single score. It triggered intervention only when drift coincided with measurable degradation in calibration error or AUC, to avoid acting on benign changes. Writing both conditions into the procedure (a drift statistic above a set level, and a measured change in false-accept or false-reject rate) gives you a trigger an auditor can follow. With sparse data per supplier, set the drift limits conservatively, or the trigger will fire on noise.
On ownership, the iFactory checklist recommends that threshold changes need quality-engineer authorisation and documented shadow-mode validation, not operator adjustment during production, because ad hoc operator changes often overcorrect. Our view is that detection can be automated while the threshold change itself keeps a named human sign-off, with the owner (plant, vendor or joint board) settled before go-live.
What evidence shows an auditor the threshold came from your own escape and cost data?
The evidence is the procedure plus its outputs: the agreed cost weights, the labelled escape and false-reject history, the trade-off curve across candidate thresholds, the chosen point with its expected error rates, and the condition that triggers recalibration. TechnoLynx builds that as a pipeline rather than a one-off analysis: confirming the cost weights and the documentation format your auditors expect, building the threshold calibration on the AOI model’s scores and your historical run data, generating the escape versus false-reject curve, confirming the chosen threshold against held-out historical incidents, and documenting it as a control-plan item with a defined recalibration trigger.
We would record the threshold as a control-plan line item, with its rationale referenced as a gauge tolerance’s would be. Re-running the same procedure on updated history then either confirms the threshold or re-derives it, and you keep both versions on file.
A repeatable threshold-setting procedure
- Fix the cost weights in writing. Price a missed defect and a false reject in money or risk terms, and check Elkan’s reasonableness condition that labelling an example wrongly always costs more than labelling it correctly. The business supplies these numbers and has to keep them current.
- Assemble confirmed outcomes. Use parts whose defect status was physically verified; noisy ground truth bends the curve and everything built on it.
- Keep tuning data away from training data. The scikit-learn documentation says never to use the same data to train the classifier and tune its threshold. Its cost-sensitive example shows the symptom when you do: a wide plateau of near-optimal thresholds that signals overfitting.
- Sweep every candidate threshold against the cost. scikit-learn’s
TunedThresholdClassifierCVpicks the cut-off that minimises a supplied business cost, using 5-fold stratified cross-validation by default. A single split hides how much the chosen cut-off varies; repeated cross-validation averages that out. - Shadow the new threshold before it goes live. Run it in shadow mode for at least one production shift, comparing its decisions with the live ones and with physically verified outcomes, as the iFactory checklist recommends. The same checklist names untested threshold changes as the most common cause of sudden spikes in false positives or escapes after a calibration session.
- Review on a fixed cycle. Regenerate the precision-recall curve from recent confirmed outcomes and review each defect class’s threshold against current data at every 90-day calibration cycle, as the iFactory checklist recommends, since the optimum moves as production data accumulates and the defect mix shifts.
Where a hard limit exists on one error type (a cap on missed objects, for instance), a cost-sensitive framework lets you set a budget on that error. Work on object detectors frames this as maximising true-positive rate while the false-positive rate stays within a pre-set budget, or the reverse, read off the ROC curve.
When a lighting or camera change shifts the scores, can you recalibrate without retraining?
Yes, when the change distorted the probabilities without compromising the model’s ranking; shifts severe enough to compromise ranking require retraining. The 2026 deployment-reliability study puts the intuition clearly: moderate shifts mainly distort calibration and can be handled by recalibrating, while severe shifts compromise ranking and require retraining. TechnoLynx sets this up with your quality and audit teams: defining which changes count as routine and which as major, building the recalibration step (reference sample collection, threshold computation, image normalisation where needed) into the AOI software, testing the recalibrated threshold against a fixed reference defect panel comparing false-accept and false-reject rates before and after, and connecting re-threshold events to monitoring so a full re-qualification is triggered only when the limits say so.
What should trigger a re-threshold
The 2026 anomaly-detection study recommends considering recalibration after changes to the detector, camera, illumination, tooling, material or production process, or when monitoring shows the normal-score distribution has shifted, with the new threshold based on a sample representing the new operating condition. Slow drift counts as well as discrete events. The iFactory checklist states that a 15% fall in LED intensity from the commissioning baseline is enough to push image brightness outside the training range and generate false positives, and it describes lighting drift as too gradual to trip any single-event alarm. Monitoring image brightness against the commissioning baseline therefore belongs in the trigger list alongside the score distribution.
Ways to re-threshold without touching the weights
Several mechanisms change the decision while leaving the trained model alone. A recalibration map refitted on recent labelled data adjusts the probabilities while preserving the model’s ranking. Saerens et al. (2002) give an EM procedure that adjusts a classifier’s outputs to new class priors without refitting, even when the new priors are unknown. For anomaly detectors, Anomalib’s normalisation centres the threshold at 0.5 and exposes a sensitivity parameter that moves the effective threshold after deployment.
The deployment-reliability study charged retraining at five times the cost of recalibration in its cost model, reflecting engineering, compute and governance burden. Its drift-triggered policy needed one retraining and two recalibrations over nine annual windows, against nine retrainings for rolling retraining, while keeping competitive discrimination. The same study warns that recalibrating mechanically on small time slices can itself make probabilities oscillate, so recalibration frequency should be tuned to observed drift rather than run as a ritual.
How many samples a new threshold needs
The number of normal images a new threshold needs follows from exact sample planning. The 2026 anomaly-detection study shows that with 150 calibration images of normal parts, a 95%-confidence distribution-free claim is supported only for false-positive rates of 1.98% or higher, and a 1% target needs at least 299 normals. Those samples must be effectively independent; images correlated by batch, tool state or repeated specimen have to be counted at the level of the independent unit. For defect recall, the iFactory checklist validates against confirmed defective samples from every defect class before release.
Where recalibration stops working
Tomani et al. (CVPR 2021) show that standard post-hoc calibration methods produce highly overconfident predictions under domain shift. Tuning the calibrator on a deliberately perturbed validation set substantially improved calibration under shift in their experiments. A new camera geometry, a changed defect population or a new material is the point where we would stop recalibrating and plan retraining and re-qualification.
On Gauge R&R, Micro Precision’s guidance is to repeat a study when an instrument is replaced, repaired or modified, when the measurement process changes, or when SPC data shows an unexplained measurement shift. That maps onto a change-by-change response, sketched below; the boundaries only satisfy an auditor if the procedure defining them was approved before the change, not written to justify a result.
| Change | Likely effect on the model | Response | Evidence before release |
|---|---|---|---|
| Gradual LED decline | Brightness leaves the training range, causing false positives | Restore lighting or re-threshold on a fresh reference sample | Shadow run against verified outcomes |
| Lamp replaced with the same specification | Illumination change | Recalibrate on a sample representing the new condition | Full calibration after lighting maintenance |
| New camera, lens or working distance | Geometry and resolution change | Regenerate the lens distortion profile, then re-threshold or retrain depending on panel results | Partial or full Gauge R&R per the change protocol |
| New material, supplier or process | Defect population may change | Treat as major: assess retraining | Full re-validation |
Turning a continuous score into a flagged decision a reviewer will accept
Most anomaly detectors output an unbounded score rather than a label, with a range that differs between models, so a threshold is what maps it to normal or anomalous. Where a new model replaces a legacy pass/fail tool, we would calibrate the cut-off on historical cases whose legacy outcome is known, matching the legacy flag rate or minimising cost-weighted disagreement, and treat legacy labels as noisy evidence rather than truth.
Should the cutoff vary by product, zone or condition? Vary it where the variation is real and documented: the iFactory checklist notes that a threshold profile designed for a dark-coloured product produces excessive false positives on a light-coloured one, even with a correct model. Each extra profile is also another parameter to govern and apply consistently, so a single cutoff remains the easier one to audit unless the accuracy cost of using one is shown.
For the rationale document itself, we would lead with the chosen operating point and the false-negative/false-positive trade-off accepted there, and attach the full ROC or precision-recall curve as supporting evidence; the exact format a standards board expects should be confirmed with that board.
Thresholds decide about this part; survival models estimate when a machine fails
A defect threshold makes a decision about an item already in front of the camera, using a score for that item. Survival and remaining-useful-life models answer a different question: when a piece of equipment is likely to fail, estimated from run histories where most units have not yet failed and are therefore censored. Those models output a distribution over time, and a threshold only enters afterwards, for example as the failure probability within a maintenance window at which you act. The calibration discipline carries over (the probabilities still have to mean what they say), but censoring, sparse failure labels and changing load regimes make it a separate modelling problem, and the methods above for setting a pass/fail cutoff do not settle it.
FAQ
What is a proper scoring rule?
A proper scoring rule is a loss that is minimised by reporting honest probabilities; log-loss and the Brier score are the common examples. scikit-learn’s cost-sensitive example tunes the model with log-loss so its probabilities are as accurate as possible, independent of the threshold chosen afterwards.
