Every logistics operation runs on exceptions. Most shipments move without intervention; a minority go wrong, and the entire value of an operations team is in finding those early enough to do something. This is an obvious application for prediction and the obvious implementation usually fails.
Why the risk score gets ignored
A dispatcher receiving a list of shipments with risk scores has been given a ranking and no reason. On day one they work the list. By week three they have found a case where the top-scored shipment was fine and one they knew was in trouble scored low, and after that the list is background noise.
This is not irrationality. The dispatcher is accountable for the outcome and cannot defer to a number they cannot interrogate. Any tool that asks an operator to act against their own judgment without showing its reasoning is asking for something people correctly refuse.
Operators do not reject models because they are wrong. They reject them because they cannot argue with them.
What to build instead
Not a score. A stated exception: this shipment has not scanned in eleven hours against a lane where the median gap is three, the carrier has missed two of its last nine appointments at this facility, and the receiving window closes in six hours.
That is three facts and an implication. Every one of them is checkable. The dispatcher can immediately agree, disagree, or notice that the receiving window moved and the system does not know.
- State the observation, the baseline it deviates from, and the consequence window
- Carry the source event identifiers so any claim can be opened
- Rank by time-to-consequence, not by abstract probability
- Capture the operator's disposition as a labeled signal for later evaluation
- Show what the system does not know — missing telemetry is itself an exception
The language model's actual job
It is not the prediction. Deviation detection against lane baselines is a statistics problem and should be solved as one, deterministically, so the same inputs always yield the same exception.
The model reads the unstructured layer that surrounds the shipment — carrier emails, driver notes, facility comments, EDI free-text segments — and turns it into structured events with spans. That content routinely contains the earliest signal of a problem and is almost never parsed today. Turning it into events is where the incremental detection actually comes from.
Why operators stop using exception tools
Relative weighting from delivery practice, not a measured statistic — shown to rank where attention belongs.
Measuring it the way operations measures it
Precision and recall on a historical set will not persuade an operations director. The number that matters is how many exceptions were surfaced early enough that intervention was still possible, and of those, how many were acted on.
The second half of that metric is the honest one, because it measures whether the tool was trusted. A system with excellent detection and a five percent action rate has not improved operations; it has produced a well-informed report nobody uses.
The anatomy of a good exception
An exception that gets acted on has a consistent structure, and it is worth specifying because most tools emit something less.
| Component | Example | What it does for the dispatcher |
|---|---|---|
| Observation | No scan in eleven hours | A checkable fact, not a score |
| Baseline | Median gap on this lane is three hours | Establishes that eleven is abnormal here |
| Corroboration | Carrier missed two of nine recent appointments at this facility | Raises confidence without asserting cause |
| Consequence window | Receiving closes in six hours | Converts concern into a deadline |
| Action affordance | Carrier contact, appointment reschedule, customer notification | Removes the lookup step |
The consequence window is what makes ranking meaningful. Sorting by probability puts an unlikely problem with three days of slack above a likely one closing in two hours. Sorting by time-to-consequence matches how the desk actually works.
Baselines have to be local or they are noise
A single network-wide threshold produces exceptions on every lane where transit is legitimately long and misses real problems on lanes where it is short. The baseline has to be specific enough to mean something.
Lane, mode, carrier, facility, day of week, and season all shift the normal pattern materially. A drop trailer program at a facility with an overnight gate generates scan gaps that are entirely routine and would fire constantly against a generic threshold.
The practical construction computes baselines at the finest granularity with enough history to be stable, and falls back progressively when it is not — this carrier on this lane, else this lane, else this mode and distance band. The fallback level should be visible in the exception, because "we are comparing against a broad baseline" is information the dispatcher can use.
Absence of data is the exception people forget
Most detection logic triggers on an observation. In freight the most common serious problem produces no observation at all: telemetry stops, the carrier's integration silently fails, the driver's app is not running.
A system watching for anomalous events will see nothing and report nothing, and a shipment quietly disappears from view until it fails to arrive. Explicitly modeling expected observation frequency, and firing when expected events do not occur, catches a class of problem that is otherwise invisible.
This also produces a useful operational signal at the aggregate level. A sudden rise in silent shipments for one carrier is usually an integration failure rather than an operational one, and knowing that within hours rather than days prevents a week of blind shipments.
The unstructured layer is where the early signal is
The earliest indication of a problem is frequently in text, not telemetry — a driver message, a facility comment, an email from the carrier, a free-text EDI segment. Almost none of it is parsed, and it routinely predates the telemetry deviation by hours.
Extracting structured events from this traffic is the strongest single application of a language model in the workflow. The output is an event with a type, a shipment reference, a timestamp, and the source span — never a summary, and never an inference about what will happen.
- Controlled event vocabulary, so downstream logic can consume it
- Shipment reference resolved against the system of record, with unresolved states preserved
- Source span retained so the dispatcher reads the original text in one click
- No causal or predictive language in the extracted event itself
- Low-confidence extractions routed for review rather than discarded
Measuring adoption, not just detection
The evaluation that matters to an operations leader has two halves and most programs report only the first.
Detection: of the shipments that went wrong, how many were surfaced early enough that intervention was still possible. Adoption: of those, how many were actually acted on.
The second number is a trust measurement. A system with strong detection and low action rate has not improved operations — it has produced a well-informed report that people scroll past. Tracking dismissals by reason is the cheapest diagnostic available, and the reasons are usually specific and fixable: the baseline was wrong for this lane, the appointment had already moved, the exception fired too late to matter.
Each of those is an engineering fix. None of them are visible in a precision-recall table.
The customer conversation is the real deliverable
Operations teams are measured on shipments and judged on communication. A delay the customer learns about early is a manageable problem; the same delay discovered by the customer first is an account risk regardless of the operational outcome.
That reframes the value of early exception detection. The hours gained matter less for recovery — many delays cannot be recovered — than for notification. A system that surfaces a problem six hours before the receiving window closes may not save the delivery and reliably saves the relationship.
Which suggests a feature most exception tools omit: a customer-facing summary generated from the same grounded facts, stating what happened, what is being done, and the revised expectation, without speculation about cause. Written from the event record rather than freely composed, it is safe to send and it is the artifact the account team actually needs.
Carrier scorecards built from exceptions
Exception data accumulates into something more valuable than the exceptions themselves — an evidence base about carrier and facility performance that procurement has historically had to argue about from anecdote.
- Appointment adherence by carrier, lane, and facility
- Telemetry reliability — how often shipments go silent, and with whom
- Time-to-response when contacted about an exception
- Recovery rate once an exception is raised
- Documentation accuracy on handoff
Presented at a rate negotiation with the underlying events attached, this changes the conversation from an assertion about service quality into a reviewable record. Carriers respond to it, and the ones that respond well are usually the ones worth keeping.
What to do about the silent shipment
The absence-detection point deserves an operational answer, not just a detection mechanism. When telemetry stops, the useful response is graduated rather than binary.
A short gap on a lane with known dead zones is noise. A gap exceeding the lane's historical maximum warrants an automated carrier ping. A gap with a consequence window inside it warrants a human. And a cluster of gaps on one carrier warrants an integration check rather than a shipment-by-shipment chase.
Encoding that ladder is what turns a detection into a workflow, and it is the difference between a dashboard that reports silence and a system that resolves it.
Frequently asked questions
Not always. Much of that traffic is templated and yields to parsing. The model earns its cost on the genuinely free-form remainder, which is small in volume and high in signal.
Useful when they carry an interval and the basis for it. A point estimate with no interval invites exactly the trust failure described above.