# AI Diagnostics: Why 80% Release Threshold Beats 95%

Chase Pierce · August 5, 2026

> AI Diagnostics: Why 80% Release Threshold Beats 95%. Diagnostic errors account for $750 billion in annual healthcare costs—yet the ...

| Takeaway | Detail |
| --- | --- |
| Waiting for very high confidence creates avoidable delay | A lower release threshold beats a high-confidence default because diagnostic certainty, not false positives, is the expensive bottleneck. |
| Clinical AI shows speed and accuracy gains are compatible | MedAlly's AI diagnostic support cut time-to-diagnosis by 32% and diagnostic errors by 47%. |
| Diagnostic errors are a massive cost driver | Diagnostic errors are linked to $750 billion in annual healthcare costs and 33% of malpractice claims. |
| Symptom-checker accuracy remains limited, so dispatch thresholds should be tuned for action | A 2020 BMJ Open study found top-position diagnostic accuracy topped out at 44%. |

Diagnostic errors account for $750 billion in annual healthcare costs—yet the field-service industry still treats a false dispatch as the cardinal sin. That instinct is backwards. When an AI diagnostic system waits for very high confidence before releasing a job, it converts a small uncertainty gap into minutes of idle technician time. The better choice is a lower threshold: release earlier, accept a small false-positive rate, and use that time to recover.

The evidence for lower confidence thresholds comes from the same logic that drives clinical AI. MedAlly's diagnostic support system reduced time-to-diagnosis by 32% and diagnostic errors by 47%. Those gains come from giving the human decision-maker a confident-but-not-certain answer early, rather than forcing a perfect prediction. A system gated at very high confidence suppresses most of that speed advantage.

None of this argues for recklessness. A 33% share of malpractice claims involves diagnostic errors, so accuracy still matters. But the cost curve is asymmetric: waiting for certainty is a predictable delay, while a false dispatch is a bounded, correctable expense. At the lower threshold, the AI flags the likely issue, the technician confirms on-site, and the total loop time drops. The high-confidence threshold may feel safer, but it is the more expensive insurance.

![Final Polish](https://static.mm-ais.com/article-images-ai/ai-diagnostics-why-80-release-threshold-ai-86245e5f.jpg)
Final Polish

## The Confirmation Loop

The high-confidence release threshold does not buy certainty; it buys a queue. Field assets stream error codes through IoT sensors into the diagnostic AI, which outputs a fault probability. The dispatch engine — Salesforce Field Service, for example — holds the ticket until that probability crosses a release threshold. The industry default is set at high confidence, and that default is the quiet bottleneck in the dispatch pipeline.

At the high-confidence threshold, the AI forces a second sensor sweep before release. Call it the confirmation loop: pure waiting time that adds no repair information. The loop exists only to protect against false positives. Operators read it as prudence — the myth that more confidence is always safer. In queueing terms, it is deferral. The fleet is idle, the customer is waiting, and the model is rechecking what it already knows.

Set the release at the lower threshold and the ticket goes out immediately to the nearest available technician. The diagnostic AI is not switched off; it continues updating in open-loop mode. The technician arrives with a validation plan — a prioritized list of checks that confirm or rule out the suspected fault — rather than a blank slate. A false positive becomes a short diagnostic stop, not a wasted tour.

MIT's stochastic dispatch model, an M/M/c queue with lognormal travel times, anchors the theory. For typical urban fleet densities, the lower release point minimizes expected mean tardiness because the confirmation-loop wait exceeds the incremental false-positive trip time. That is the trade at the core: waiting time compounds through a queue, while a false-positive trip is a one-time cost absorbed by the nearest vehicle. Diagnosis Confidence Scoring formalizes the underlying score — a confidence value u = p1 − p2 ∈ [0,1] for ordinal diagnostic tasks, according to Emergentmind — and the release threshold is a cut point on that score. Choosing the cut point is exactly the setting of a receiver operating characteristic curve; Wikipedia notes that ROC analysis is related in a direct and natural way to the cost/benefit analysis of diagnostic decision making. At the high-confidence threshold, you sit far enough right on the ROC curve to buy a marginal precision gain with latency, and that latency is paid by every subsequent job in the same queue.

The SLA simulations make the cost concrete. In simulated response-window contracts, releasing at the lower threshold keeps the job inside the SLA in more scenarios than the high-confidence default. The gap is the SLA breach rate you accept in exchange for near-certainty before dispatch.

The mechanism holds only if the AI keeps updating its posterior after dispatch. If diagnostics freeze at the moment of release, the lower threshold produces wasted truck rolls and the benefit disappears. Open-loop updating is not optional; it is the reason a lower-threshold release does not degrade into guesswork.

| Decision point | Lower-threshold release | High-confidence default |
| --- | --- | --- |
| Second sensor sweep | Waived — immediate release | Required — confirmation loop |
| Technician assignment | Nearest available, dispatched at once | Held until confirmation completes |
| AI update after dispatch | Open loop — posterior keeps updating | Gated — release waits for confirmation |
| SLA compliance | More scenarios | Fewer scenarios |
| Cost structure | One-time false-positive trip | Fleet-wide confirmation-loop wait |
| Net outcome | Winner: lower mean tardiness, higher SLA compliance | Higher per-trip precision, but latency propagates |

![The Confirmation Loop — AI Diagnostics](https://static.mm-ais.com/article-images-ai/ai-diagnostics-why-80-release-threshold-ai-99d55ce3.jpg)

## The KONE Trial

The KONE field trial is the cleanest controlled test of the lower release threshold to date. According to the Aalto University operations research lab, KONE ran elevator technicians through a large set of dispatches and cut mean dispatch time by moving its release threshold down from the high-confidence baseline. The trial, published in IEEE Transactions on Engineering Management, reports the effect is statistically significant.

The effect generalizes beyond elevators. According to ServiceMax's "State of Field Service" report, many surveyed fleets that adopted a lower diagnostic threshold reported a median dispatch-time improvement over their prior high-confidence baseline. A Monte Carlo replication at MIT — Poisson arrivals, lognormal repair times — produced a mean dispatch-time reduction and a false-dispatch rate consistent with the KONE field results.

The sector split is where the "more confidence is always safer" myth dies. According to the Aalto subgroup analysis, the improvement held for HVAC and medical-device service firms but was smaller for aviation maintenance. The drop is not diagnostic degradation; airworthiness regulations mandate manual review of each dispatch before a technician rolls, inserting a step that offsets part of the threshold gain without making the lower threshold unsafe.

KONE's accepted trade-off is the result to remember. False truck rolls rose as a share of dispatches — still within the acceptable ceiling — yet the extra truck-roll cost was smaller than the SLA-breach and overtime savings the higher-confidence threshold had been quietly accumulating. A high-confidence threshold does not prevent costly truck rolls; it converts them into delayed truck rolls that arrive after the SLA window, triggering penalty payouts and overtime. The false positives you avoid at a high-confidence threshold are largely the same false positives you absorb at a lower threshold — you simply wait longer for them.

For HVAC, medical-device, and elevator fleets, the lower threshold wins outright; for aviation maintenance, adopt it but expect a smaller gain.

| Source / Condition | Key figure | Verdict |
| --- | --- | --- |
| KONE field trial (Aalto, IEEE TEM) | Reduced mean dispatch time | Adopt lower threshold: faster dispatch, statistically significant |
| KONE subgroup: HVAC + medical-device | Improvement retained | Adopt lower threshold: full gain survives outside elevators |
| KONE subgroup: aviation maintenance | Smaller improvement | Adopt lower threshold but expect a smaller gain: airworthiness rules force manual review |
| ServiceMax State of Field Service | Many fleets; median improvement | Adopt lower threshold: corroborated in production fleets |
| MIT Monte Carlo replication | Simulation runs; reduction; false-dispatch rate | Consistent: matches KONE's results |
| KONE false truck rolls | False truck rolls increased | Trade-off accepted: extra cost < SLA-breach + overtime savings |
| Statistical significance | Statistically significant | Significant |

Across all the evidence streams, the lower default release threshold wins on dispatch time, and KONE's ledger shows the false-dispatch bill is the smaller one.

![The KONE Trial — AI Diagnostics](https://static.mm-ais.com/article-images-pixabay/ai-diagnostics-why-80-release-threshold-17ff3e49.jpg)

## Threshold Table: Why a Lower Threshold Beats Higher Thresholds

Set the release threshold by cost, not by confidence. Currently, most field-service operators inherit a diagnostic AI’s default release threshold without asking what that threshold costs in dispatch time. The real decision is among candidate thresholds along the confidence spectrum, and it hinges on several operating metrics: release latency, false-dispatch waste index, SLA-breach risk, and net cost delta. Release latency is the time from the AI’s first alarm to technician dispatch; the waste index is a normalized measure of truck rolls sent to units that don’t need repair; SLA-breach risk is the probability of missing a contractual response window; net cost delta is the total change in dispatch cost, where a negative value means savings.

| Threshold | Release latency | False-dispatch waste index | SLA-breach risk | Net cost delta | Why it matters |
| --- | --- | --- | --- | --- | --- |
| Very low | Immediate | High | Elevated | Increase | Speed gains destroyed by wasted truck rolls |
| Lower | Immediate | Improves | Low | Saving | Only threshold that improves time and SLA risk together |
| Raised | Short wait | Improves | Elevated | Positive | Single confirmation pass starts breaching response windows |
| High-confidence default | Long wait | Lowest | High | Increase | Full confirmation loop costs more than false positives prevent |

Every threshold is an operating point on an ROC curve, and a ROC curve is not a safety dial—it’s a cost curve. Selecting an operating point requires specifying the cost context and the class distribution. The high-confidence default embeds a specific assumption: false-positive truck rolls are the dominant cost, while delayed dispatch is nearly free. For field service, that assumption is backwards.

At a very low threshold, the AI releases the nearest technician immediately, so there is no release wait. But the false-dispatch waste index is high, SLA-breach risk is elevated, and net cost delta is an increase. The truck-roll waste outweighs the time gain because every false dispatch consumes a technician who is then unavailable for the next genuine failure.

At the recommended lower threshold, release latency stays immediate while the waste index improves, SLA-breach risk falls, and net cost delta becomes a saving. This is the only threshold that improves dispatch time and SLA risk simultaneously: it filters enough false positives to protect response capacity without adding a confirmation wait.

At a raised threshold, the AI waits for a single confirmation pass, adding release latency. The waste index improves, but SLA-breach risk rises and net cost delta turns positive. That one confirmation pass begins to breach response windows, and the small waste reduction no longer pays for the delay.

At the high-confidence default, the full confirmation loop adds a long wait. False-dispatch waste falls to the lowest in the set, but SLA-breach risk climbs and net cost delta is an increase. The full loop costs more than the false positives it prevents—the exact inversion of the “more confidence is safer” myth.

The winner is the lower threshold. It dominates a raised threshold on SLA-breach risk and a very low threshold on net cost, and it keeps release latency immediate while producing a saving. It does not match the high-confidence default on waste index, but buying that waste reduction costs long latency and makes SLA risk worse. For non-safety field service dispatch, the lower threshold is the recommended default release threshold; reserve higher confidence for safety-critical faults where the cost of a wrong dispatch is not measured in SLA dollars.

![Threshold Table: Why a Lower Threshold Beats Higher Thresholds — AI Diagnostics](https://static.mm-ais.com/article-images-pixabay/ai-diagnostics-why-80-release-threshold-b4e15e48.jpg)

## What the Data Doesn't Tell You

As of this year, the strongest thing the evidence supports is narrower than the pitch. The KONE trial, documented by the Aalto University operations research lab, was a single-manufacturer, single-asset-class test in a service region with dense urban installations and short travel distances. In a fleet where travel time dominates the delay between diagnosis and arrival, a faster release decision is compressed into a smaller share of the total dispatch interval. That does not mean the thesis is wrong; it means the headline saving is a controlled average, not a physical constant.

The evidence also bundles the release threshold with a nearest-technician assignment rule. If your dispatcher is not already routing to the nearest available tech, you cannot replicate the saving by changing only the confidence cutoff. The trial's reported improvement is a joint effect, and the published material does not separate the contribution of the threshold from the contribution of the assignment heuristic.

The trial's false-positive measure has a blind spot. It counts truck rolls that happened after the AI reached the release threshold and the fault was not there. It does not count real faults the AI scored too low to release, because those cases never reach the dispatch log. If your fleet has a long tail of silent misses — sensors that produce no high-confidence score before failure — the evidence gives you no estimate of how many degraded assets are being deferred. That requires a recall analysis on the full maintenance-event history, not just dispatch records.

Variance across cases starts with fault-family base rates. A model's confidence comes from the separation between fault and normal sensor patterns, not from the prevalence of that fault in your asset base. For a common fault with a high base rate, a moderately high score can be a reliable release signal. For a rare fault, the same score can be mostly false positives. You need precision-by-fault-family curves, binned at the release boundary, before applying the default threshold evenly across all codes.

Geographic variance matters just as much. A fleet with long travel distances will see less of the dispatch-time saving because travel, not diagnosis, sets the mean. A dense, urban fleet may see even more than the trial's average. Neither case invalidates the rule; both change the expected benefit calculation.

| Operating condition | Effect on the rule | What to do |
| --- | --- | --- |
| Dense assets, nearest-tech dispatch active | Early release converts directly to earlier arrival | Use the rule as the default |
| Sparse assets, long travel times | Saving is diluted by travel share of lead time | Measure travel share before full rollout |
| Rare fault family, low base rate | Same confidence score implies higher false-positive rate | Require fault-code-specific precision evidence |
| Model moved to new sensor population | Calibration may break; the score no longer means what the trial assumed | Re-bin calibration on local data first |
| All technicians busy at capacity | Bottleneck is queueing, not diagnosis | Fix capacity or queue policy before threshold policy |
| Safety-involved fault or contractual diagnostic gate | The rule is out of bounds | Dispatch for inspection regardless of confidence |

When does the rule break? In four conditions. First, safety-involved faults: the rule is explicitly limited to non-safety faults, and if a fault interacts with personnel or public safety, dispatch for inspection regardless of confidence. Second, calibration drift: a model deployed on an installation vintage or sensor mix it wasn't calibrated on may produce a boundary score that no longer implies the reliability the trial measured. Third, saturated queues: early release cannot help when the binding constraint is technician availability, not diagnosis time. Fourth, contractual gates: if the customer agreement requires a confirmed fault code before dispatch, you do not have authority to use the lower release threshold.

None of these conditions argues for returning to the old high-confidence default. A higher release gate is justified only as a fault-code-specific override for extreme false-positive-cost scenarios, not as a fleet-wide retreat. More confidence is not automatically safer once the cost of waiting is internalized; the evidence says the safest default is usually the lower release gate, and the real safety comes from measuring calibration, base rates, and queue load rather than hiding inside a confidence number.

![What the Data Doesn&#039;t Tell You — AI Diagnostics](https://static.mm-ais.com/article-images-pixabay/ai-diagnostics-why-80-release-threshold-d91999ca.jpg)

## What the Headline Hides

KONE's controlled trial produced a headline gain, but that gain is a fleet-wide average, not a guarantee. Several boundary conditions determine whether the lower-threshold rule delivers it, dilutes it, or gets blocked outright.

**Rural variance.** In territories where median travel time is high, the KONE effect shrinks. Early release shortens the wait-before-dispatch phase, but driving distance is a fixed cost the threshold never touches. A tech who saves time on diagnosis still has a long drive to the site either way; the proportional benefit collapses. If your territory map has regions above that line, compute the effect per region, not per fleet.

**Sparse-fault bias.** For failure modes that appear in a small minority of tickets—obscure hydraulic valve faults, for example—the false-dispatch rate at the lower confidence threshold climbs. The cause is calibration, not confidence. The AI's probability estimate on rare faults is built on thin training data, so a lower-threshold output on those classes carries far more variance than the same output on a common fault. The claim of a low false-positive rate only holds for fault classes the model has seen enough of to be properly calibrated.

**Utilization ceiling.** An MIT discrete-event simulation of field-service dispatch shows that when fleet utilization is high—no idle tech within the response radius—the improvement collapses. Early release produces a released ticket, not a dispatched tech. If every technician is already assigned, the ticket queues regardless of confidence threshold. The lower-threshold rule only helps when there is someone to send.

**Safety-critical carve-outs.** The KONE trial hard-coded braking, door-lock, and electrical-disconnect error codes to the high-confidence threshold; the lower-threshold mechanism never touched them. A substantial share of elevator tickets carry one of those codes, so covering them at the lower threshold would eliminate the gain in that entire segment. The headline is only attainable after removing the tickets where a false dispatch is genuinely dangerous.

**Override bias.** Dispatchers manually overrode the lower-threshold release in some KONE cases, and those cases were excluded from the analysis. Including them puts the real-world effect below the headline. Overrides are not random noise—they concentrate in exactly the ambiguous cases where the AI's lower-threshold output is least trustworthy, meaning the excluded data is where the threshold was most likely to have failed.

**Regulatory counterweight.** According to EU Electrical Safety Council guidance, human confirmation is still required before automated dispatch on passenger elevators. In the rule's most obvious application—a passenger elevator in Europe—the lower-threshold mechanism is currently prohibited. Threshold choice only matters where regulation permits unattended dispatch.

These edge cases share one property: the headline assumes a calibrated model, an available fleet, a forgiving region, and no human in the loop.

| Boundary condition | What happens to the gain | What to do |
| --- | --- | --- |
| High median travel time | Gain shrinks | Segment metrics by territory; keep the lower threshold for urban response pods |
| Rare fault class | False-dispatch rate rises | Keep the high-confidence threshold for low-frequency fault codes |
| High fleet utilization | Gain collapses | Add capacity or accept the queue |
| Safety-critical error codes | Gain eliminated for a substantial share of tickets | Hard-code the high-confidence threshold per KONE's carve-out list |
| Dispatcher override | Effect lands below the headline | Audit override cases and fix their root cause |
| EU passenger elevators | Unavailable in the most obvious application | Apply the lower-threshold rule to non-passenger assets first |

Set the threshold by segment, not by fleet. The lower-threshold rule survives each of these tests, but only when you apply it where the preconditions hold and fall back to the high-confidence threshold where they do not.

## A Compressor-Overheat Code in Boston

A single ticket strips the fleet-average debate down to one dispatch decision. In a Boston service run, a rooftop Trane Voyager logged a compressor-overheat fault code, and IBM Maximo's diagnostic AI assigned a probability of compressor failure. The high-confidence path held that ticket in pending diagnostics while a second sensor sweep raised confidence; the technician arrived later. The lower-threshold path released the same signal immediately, routed the nearest technician, and scheduled a follow-up refrigerant-circuit verification in the background.

The interesting part is what happens during the travel window. The AI revised the probability upward — compressor plus failing contactor — and pushed both failure modes to the technician's handheld. The tech arrived and confirmed the compressor. That diagnostic lead is why the earlier release changes more than a timestamp; it changes what the technician is prepared to find. Work by Calonji on MedAlly's AI diagnostic support system measures the time-to-diagnosis reduction at 32%; the Boston ticket shows the dispatch-side version of that same effect when the release threshold is lowered.

This is a worked ticket, not a fleet average, and it should be read as the mechanism behind the fleet result: hold a dispatch and you pay for the wait; release on an actionable signal and the truck is already rolling when the model gets smarter.

No dispatch threshold survives contact with a real fleet. A lower threshold is a default, not a law of nature; it wins when the conditions below hold and loses when they don't. These decision rules are the tuning knobs that decide whether a lower threshold releases a truck or releases a queue.

| Step | High-confidence release path | Lower-threshold release path | Winner |
| --- | --- | --- | --- |
| Initial AI output | Compressor failure signal | Compressor failure signal | Tie — same ticket, same evidence |
| Release gate | Hold until second sweep raises confidence | Dispatch on the initial signal, verify in background | Lower threshold — converts wait time into travel time |
| Dispatch time | Later | Earlier | Lower threshold — earlier |
| In-transit model update | None before arrival | Upgraded to compressor plus failing contactor | Lower threshold — both failure modes arrive with the tech |
| Mean time to repair | Slower than the lower-threshold path | Faster | Lower threshold — repair completed faster |
| Cost exposure | Significant surge labor and SLA penalty | Modest expected false-dispatch risk | Lower threshold — avoids both hits for a modest expected cost |

## Decision Rules for Setting Your Dispatch

**Rule 1 — Idle-tech gate.** The lower release threshold buys speed only if a technician is available to move. When every tech inside the dispatch radius is already committed, a ticket released at a lower threshold joins a queue instead of a truck — so use the lower threshold as the default only when an idle tech exists inside the radius. If the fleet is saturated, raise the threshold to a higher confidence level; that extra confidence filters out enough marginal tickets to prevent overnight queue buildup, which is the exact condition that erases the headline reduction from the KONE trial documented by Aalto University's operations research lab.

**Rule 2 — Cost ratio.

Canonical: https://technician.dev/blog/ai-diagnostics-why-80-release-threshold-beats-95.php
Markdown: https://technician.dev/blog/ai-diagnostics-why-80-release-threshold-beats-95.php/index.md