A severity score is learned from how past alerts were actually resolved, as in AlertRank. A calibrated confidence score decides whether the system may act on its own. The thresholds are chosen on held-out labelled data before they go live, and only low-confidence cases go to people. On alert data from a top global commercial bank, the AlertRank framework reached an average F1-score of 0.89. At 100% recall it cut the number of alerts engineers had to examine by about 20%. The bank’s rule-based approach, by contrast, found severe alerts with a precision of only 0.43 and a recall of 0.68.

This is production reliability engineering, which is a different job from model accuracy work. Unit tests cannot catch alert fatigue or missed events. The work delivers artefacts, such as eval harnesses and alert-quality work, that catch those failures before customers do. A dashboard is not the deliverable. The sections below apply this pattern to network operations, fraud screening, sensor fusion and LLM-as-judge quality gates in turn.

Severity, confidence and spread: the three questions a triage score answers

Severity answers “how bad is this if it is real?” Confidence answers “how likely is it to be real?” A spread or virality factor, where the domain has one, answers “how fast does waiting make it worse?” Keep the three apart. A combined score that mixes them hides why an item was escalated, and an operator who cannot see the reason stops trusting the queue.

Raw confidence should not be taken at face value. Guo et al. (2017) found that modern neural networks are poorly calibrated. Their predicted probabilities do not match how often the model is actually right. Temperature scaling, a single-parameter fix applied after training, calibrates them surprisingly well on most datasets. The CHiL(L)Grader authors (2026) report that instruction-tuned LLMs give confidence scores near 0.99 even to wrong predictions, so raw confidence cannot be used to decide what to defer. They measure miscalibration with Expected Calibration Error (ECE) and treat an ECE below 0.1 as acceptable in practice. Calibrate first and check ECE on held-out data. Only then let a confidence number route anything.

What confidence threshold should send a detection to human review?

Choose the threshold by sweeping it over a held-out, fully labelled calibration set. Take the largest value that still meets a reliability target, set in advance, for the cases the system accepts. In the CHiL(L)Grader study, raising the gate from 0.5 to 0.8 on one dataset cut automated coverage to 44.6%. It also raised agreement with expert grades (quadratic weighted kappa) from 0.602 to 0.840. The gate separated trustworthy cases from uncertain ones. On a second dataset (DAMI), after one human-correction cycle, the accepted 35% of responses reached 0.882 and the rejected ones only 0.535. Of the rejected samples, 81.2% were in fact wrong predictions.

The target can be turned into a guarantee. Geifman and El-Yaniv (2017) give a method in which the user sets a desired error rate. With probability of at least 1−δ, the classifier then rejects enough inputs to keep test error at or below that rate. In high-stakes systems, errors do not all cost the same. A benchmark of 3,150 runs found that standard marginal conformal prediction under-covers rare, costly minority classes, with minority coverage as low as 0.5% on some datasets. Class-conditional (Mondrian) conformal prediction restored minority coverage, improving it by an average of 61.7 percentage points. For each dataset, the authors also worked out the break-even point at which deferring to a human becomes cost-effective.

Low confidence is not the only reason to route a case to a person. Future AGI’s guidance on review queues lists further triggers: high business risk regardless of confidence, disagreement between two automated scorers, user-reported problems and novel inputs. It also insists on a random sample of everything else, because without one the quality estimate is biased by construction. For high-risk AI systems under the EU AI Act, Article 14 requires oversight in proportion to the system’s risk, autonomy and context. The system must enable the people doing the oversight, as appropriate and proportionate, to override the output, stop the system and stay aware of automation bias.

Handing control back to a person in a live system is covered in designing safe, low-latency fallback triggers for live AI systems. Some pipelines combine an in-house vision classifier with a third-party NLP model. In that case the two confidence scales have to be made comparable before any single threshold means anything.

Can an LLM-as-judge pre-screen reports before human QA reviews them?

An LLM-as-judge can serve as an automated quality gate that scores each report and holds it before it reaches the client. Two things need to be in place first. Its agreement with human reviewers has to be measured on a held-out labelled set, and there has to be an agreed escalation path for low-confidence or high-severity flags. TechnoLynx builds gates of this kind as production AI reliability work. The work covers defining severity tiers, deciding which flags block a report and which only advise, designing the judge and its human-agreement validation, wiring the evaluation harness into CI ahead of report generation, and monitoring agreement drift once the gate is live. The first step is agreeing the tiers and the agreement threshold with the QA team.

In a clinical-trial protocol extraction study, an LLM judge and a human expert both scored the same 95 pairs. The judge reached a Pearson correlation of 0.923 and a quadratic weighted kappa of 0.877 against the human, with a small negative bias of −0.47 points on a 0–5 scale. The authors sent the 40 lowest-confidence items to human adjudicators, who confirmed the model’s decision in 35 of them (87%). They also warn that the method may inherit model biases and still needs validation against real-world expert adjudication.

How do we check the judge agrees with human reviewers well enough to trust it?

Agreement alone is weak justification for trusting a judge. The “Trust or Escalate” work sets a confidence threshold for the judge on a small calibration set. With that threshold, agreement with humans on the cases the judge evaluates is at least 1−α, with probability at least 1−δ, for a risk level α chosen by the user. Its cascade starts with a cheap judge and escalates to a stronger model only when the first is not confident enough. On ChatArena it achieved over 80% human agreement while covering 79.1% of samples, and cheaper models than GPT-4 judged 88.1% of those. The same authors found that an LLM judge can be as accurate as a single human annotator and still be over-confident about whether most annotators would agree with it.

The authors of “Augmenting Human Evaluation with LLM Judges” list three limits of agreement-only validation: it misses construct differences, varies by dimension, and rests on unjustified sample sizes. Their framework shows that even a judge with modest predictive quality reduces the number of human reviews needed. Human effort goes furthest where the judge predicts human ratings poorly. On the agreement bar itself, Future AGI cites Krippendorff’s suggestion of an alpha of at least 0.800, or 0.667 for tentative conclusions only. It adds that the threshold is a risk decision you write down, not a law of statistics.

The decision follows from those measurements. If agreement on the validation set meets the agreed bar and the severity tiers are well calibrated, run the judge as a blocking gate before report generation. If not, keep it as an advisory signal alongside full human review. Either way, re-validate after any change to the prompt, model or data. Keep a change log as well. A model version bump moves the same numbers the gate does, and an uncontrolled before-and-after comparison cannot tell the two apart. Size the escalation queue before you turn a blocking gate on.

One tiering rule for hate speech and misinformation, or two?

A single tiering workflow can serve both categories. It needs category-specific thresholds wherever the score distributions or the harm costs differ. The governance side of these tiering decisions sits with TechnoLynx’s AI Governance and Trust work.

Use a three-band rule within one engine. Items above a high-confidence, low-ambiguity cutoff are actioned automatically, a middle band goes to a human, and items below a low-risk floor are left alone. Calibrate each cutoff per category against that category’s false-positive and false-negative costs. Standard marginal conformal prediction severely under-covers rare, costly minority classes. In that benchmark, class-conditional (Mondrian) conformal prediction restored valid minority-class coverage. The numbers have to come from your own labelled queue.

Learned scores and calibrations go stale as models and data change. One shared threshold can over-escalate one category and under-escalate the other. Two further pieces of work sit on top of these tiers: ranking a large daily flagged volume so a small policy team sees the riskiest items first, and keeping an audit trail for each decision.

If we move the threshold to cut false positives, how much sensitivity do we lose?

Plotting each metric across thresholds shows the trade-off between detection and false alarms. Retuning a fraud or alert threshold means picking the point on that curve that maximises the metric you care about. Solve it per segment where segments really differ, and validate the result by replaying labelled history before go-live. Picking one global cutoff by intuition is not a method.

A paper on Bayesian radar detection shows why the curve should carry positive predictive value (PPV). With the threshold set for a detection probability of 0.8, the false-alarm probability was 0.35 and only 70% of detections were genuine. Raising the threshold to a detection probability of 0.5 cut false alarms to 0.08 and raised PPV to 0.86. PPV is the same measure as precision.

Balancing fraud catch rate against friction for honest customers

In the BBVA dataset studied in a 2017 paper, fewer than 0.002% of transactions were fraudulent. False positives cost customers, not just analysts. The paper cites Javelin Strategy & Research (2015): after a declined card, 26% of shoppers reduced their shopping at that merchant and 32% stopped entirely. The authors fixed the operating point at a true positive rate above 89% and then measured precision, meaning the share of blocked transactions that really were fraud. On 1.852 million unseen transactions, better features cut the number of false positives by 54%, and the false positive rate fell from 8.9% to 2.96%.

Getting back under an alert-volume cap without breaching the missed-fraud SLA

Name the hard constraint first and the objective second. If the missed-fraud SLA is the ceiling, minimise alert volume within it. If the analyst team’s capacity is the cap, minimise missed fraud within that. The scikit-learn documentation describes the mechanics. You tune the decision threshold after training to maximise a business-defined utility, and you plot each metric across thresholds when more than one matters. In its insurance example the tuned threshold sat around 0.02 rather than the default 0.5. Weighting errors by money changes the answer too. When the 2017 fraud study tuned its threshold with transaction value in mind, precision dropped: the threshold accepted more false positives in order to catch high-value fraud.

Re-tuning without losing sensitivity to genuine signals

Moving the threshold alone cannot lower false positives and false negatives at the same time. Tune on data the model never trained on. The fraud study kept a separate tuning set for the threshold. scikit-learn warns never to use the same data to train the classifier and tune the threshold, because that overfits.

Threshold re-tuning procedure

1. Measure the current threshold’s catch rate, false positive rate and alert volume on a labelled historical case set, so today’s false negative rate becomes a known baseline.
2. Agree the hard constraint (missed-fraud SLA or alert-volume cap) and the objective with the business before any optimisation. The result only reflects the constraint you give it.
3. Sweep the threshold on a held-out tuning set and plot catch rate, precision and volume together. For rare events, use precision-recall rather than ROC.
4. Split into per-store, per-SKU or per-merchant-category thresholds only where segment backtests show materially different curves and each segment has enough labelled volume to avoid overfitting.
5. Replay the chosen thresholds on the historical case set, and ideally run them in shadow mode, before you push them to production.

How do we replay a historical case set before go-live?

Replay means running a candidate rule over a historical time range to see what it would have detected. Elastic’s security documentation describes a rule preview that tests a query against a historical time range and shows what it would have caught without creating real alerts. When reviewing the results, it says to confirm that known true positives appear (red-team data, for example) and to refine away obvious false positives before enabling the rule. A rule that is already enabled can be run manually over a specific incident window where the outcome is known.

How do we stop paging the team for noise without missing real incidents?

For network operations and fleet alerting, replace static global thresholds with data-driven ones. In practice that means per-segment thresholds, severity ranking learned from incident history and sequential tests where counts are low, all validated on historical incidents. The work covers per-segment thresholds, a severity ranker trained on resolution records, and a replay showing that recall holds at the lower alert count.

You need a target rate to aim at. ISA-18.2 suggests the following targets for process-plant alarm systems: 150 to 300 annunciated alarms per operator position per day (6 to 12 per hour), under 1% of time in flood, and a priority split of roughly 80% low, 15% medium and 5% high, assessed on at least 30 days of data. Those figures come from industrial process-plant alarm management, not telecom. In a severe flood the alarm system becomes a distraction and alarms are likely to be missed. A few frequent alarms often produce a large share of the load, so start with the noisiest sources.

Can the model learn from our failure history instead of fixed limits?

Yes. AlertRank assigns severity labels to alerts automatically from their resolution records. Its authors clustered alert resolution records into seven groups, and experienced engineers gave each group a severity score between 0 and 1. That gave every historical alert a graded label automatically. The model ranks alerts rather than classifying them, because a yes/no severity call invites false negatives while a ranking tells engineers what to fix first. It also copes with imbalance: non-severe alerts outnumbered severe ones by about 50 to 1. The severity threshold was chosen from training-set performance (0.86, 0.82 and 0.87 on the three datasets). After a software change, incremental retraining raised F1 from 0.68 to 0.88, so a severity model left on old data does not always hold up after a change.

Why static thresholds misfire on new traffic shapes

Even inside a statistical detector, small setting changes can swing the false-positive rate. A Princeton study of PCA-based traffic anomaly detection found that the false-positive rate for one network’s ingress routers ranged from 3.1% to 15.8% across a narrow band of the principal-components setting. The same study found that the way traffic is aggregated (by link, router or origin-destination pair) significantly changes PCA’s effectiveness. Large anomalies can also pollute the learned baseline and cause false positives elsewhere. The authors call the threshold an intuitive knob for trading false positives against total detections. If new but benign traffic shapes keep tripping alerts, look at the baseline and the aggregation before you touch the model.

Choosing the method by event volume

Signal regime	Method that fits	What controls false alarms
High-volume telemetry per segment (NOC, access-network fleet)	Per-segment thresholds plus learned severity ranking	Threshold chosen on held-out history; periodic retraining
SLO-backed services	Multiwindow, multi-burn-rate alerts	Short window confirms the budget is still burning
Low counts (new markets, small fleets)	CUSUM or other sequential change-point tests	Threshold set for a minimum average run length

The Google SRE Workbook’s suggested starting point for a 99.9% SLO is to page when 2% of the error budget burns in an hour (burn rate 14.4, with a 5-minute short window). A 3-day window at burn rate 1 raises a ticket instead of a page. Track reset time as well as detection time, because long reset times can lead to confusion or to alerts being ignored.

For low volumes, a tutorial on sequential change-point detection describes the threshold as a trade between false alarms and detection delay. You set it so the average run length before a false alarm exceeds a chosen bound, then measure the expected detection delay at that setting. CUSUM needs only constant memory per update. Its optimality, though, assumes the pre-change and post-change distributions are known exactly. For small Poisson counts, one study notes that uncertainty in estimating the baseline induces false signals. Its knowledge-based exact method detected nine major outbreaks at the cost of one false alarm.

What’s a sane way to prove fewer alarms doesn’t mean missed failures?

Score the new configuration with metrics that clearly separate genuine detectors from random predictors. A 2025 taxonomy of time-series anomaly metrics found that widely used metrics, including NAB and Point-Adjust, give random predictions inflated scores and resist that inflation only weakly. It names AUC-PR as more appropriate for rare-event detection. Where each alarm triggers a manual inspection, it recommends cost-aware metrics such as precision-at-K. Report recall on known incidents next to alerts per week, and treat any drop in recall below the agreed floor as a failed release.

How do we combine sensor, camera and telemetry signals into one score an auditor would trust?

An auditor can trust a fused score when three things hold: the rule that combines the signals is explicit, the decision threshold was chosen by a documented criterion on labelled data, and each sensor’s input is logged next to the score.

TechnoLynx takes on this kind of sensor and camera fusion as Computer Vision R&D, building an explicit combination rule and a documented threshold on labelled data, and the first step is agreeing the acceptable false-positive and false-negative trade-off with the operator.

The work runs from integrating the sensor feeds to comparing single-sensor and fused decisions on false-positive and false-negative rates, and the first step is agreeing the acceptable trade-off with the operator.

A 2018 LiDAR-camera fusion system published in Electronics shows what an auditable design looks like. It combines LiDAR and camera confidence using stated fuzzy rules. High confidence from either sensor counts, and beyond about 20 metres the system relies on the camera alone. Its two hyperparameters, α and the final detection threshold C, were chosen with a Kolmogorov–Smirnov test that maximises true positive rate minus false positive rate, which gave C = 0.65. Both datasets showed over 99.7% true positives and about 93% true negatives.

Cross-checking scale weight against what the camera saw

At a checkout, auto-clear when weight and vision agree. Send disagreements to a defined fallback, either human review or a conservative hold, rather than automatically flagging the customer. The FAIM study (Frontiers, 2020) fused weight sensing with vision for item identification in a store and reached fusion scores up to 92.6% with two cameras. A fallback queue does not remove error cost. It moves that cost into review load, which has to be sized to the expected disagreement rate.

A fused near-miss score from door sensor, CAN proximity and video

For transit safety, combine door state, proximity or CAN signals and video by default. Drop to two of the three only when retrofit cost forces it, and only after measuring how much that raises the false-negative rate. Video-only detection does not match a commercial system exactly. A PacTrans study for the US DOT compared an onboard video method with a commercial multi-camera collision-warning system. Detection overlap ranged from 81.5% to 90.7% across time-to-collision thresholds, averaging 86.9%, with the best match at 2 seconds. Where manual checking follows, the authors suggest setting the threshold slightly above 2 seconds to lower the chance of missing an event. The video pipeline’s main value was data reduction: it discarded over 99% of footage and kept only possible near-misses for expert review.

The PacTrans study compares video-only detection with another camera system, not with door, CAN and video fusion. Measure that gap on your own fleet and vehicle configurations rather than borrowing a generic figure. Before sizing the project, check whether the existing bus and CAN data can be reused without new hardware on each vehicle model. If the fused score will be cited to a regulator or customer, the threshold rationale and the sign-off record belong in a documented release decision, not only in the pipeline code.

Who can build and validate a triage model on our own alert data?

TechnoLynx can build and validate triage models on a team’s own alert data. A specialist is most useful when the thresholds have to stand up to scrutiny quickly, or when the pipeline spans vision, telemetry and LLM components. When you choose a partner, ask how they would measure the trade-off curve and replay it on your history, not just which model they would use. The work sits under Production AI Reliability.

The engagement is not for every team. Building in-house makes sense if you already have labelled incident history and an engineer who can own calibration and re-validation. If you only need to group or deduplicate alerts, the incident-management platform you already run may be enough. A team with no labelled outcomes at all should first spend a few weeks recording how alerts were resolved, because without that record nobody can validate a threshold.

A threshold is a dated decision, not a constant

Every threshold in a triage model was right for one model, one data distribution and one reviewer headcount, and all three change. AlertRank’s F1 fell to 0.68 after a software change and recovered to 0.88 with retraining, which shows that a learned score can go stale after a system change. The CHiL(L)Grader authors likewise found that the best calibration temperature depends on the dataset and has to be updated as the data changes. So record each cutoff with its date, its replay set and the constraint it was tuned against. Schedule its re-validation like a release, because a threshold nobody re-checks will drift back into producing noise or missing real events.

FAQ

How is the false positive rate calculated?

The false positive rate is the number of false positives divided by all actual negatives (false positives plus true negatives). It equals one minus specificity.

Why is it not recommended to use training data for model evaluation?

A model scored on the data it learned from looks better than it will on new data, so its threshold and performance estimates come out optimistic. The scikit-learn documentation specifically warns against tuning a decision threshold on the same data used to train the classifier, because of overfitting.