A shipment message classifier can look better when its threshold is lowered: it catches more urgent cases. The exception desk may still be worse off if the extra flags wait until tomorrow. A threshold decision needs the missed cases and the review workload on the same page.
Suppose a fictional freight team receives 1,000 messages during a shift. Human labeling identifies 100 that need urgent exception review. A classifier assigns each message an urgency score. The figures below are constructed examples, not model results, and the staffing assumptions describe no client.
Define the action before interpreting the score
In this workflow, a positive prediction puts a message into an urgent review queue. A person checks it before any customer promise or shipment change. A negative prediction stays in the normal queue; it is not deleted. This definition matters because a missed urgent message is an urgent case left in normal work, while a false alarm consumes exception-review time.
Scikit-learn separates estimating a score from choosing the action threshold. Its threshold-tuning tools optimize a chosen metric; a default cutoff does not encode a particular operation’s error costs. The application owner still has to define the decision and the relevant outcome. Scikit-learn: scores, actions and threshold tuning
Keep the score’s meaning in the record. A decision margin, a class probability estimate and a language model’s written confidence are different quantities. Do not compare a new vendor’s 0.9 with the old model’s 0.9 as if they were interchangeable. If a model supplies no supported numerical score, an invented confidence field is a poor foundation for this policy.
Compare errors and queue size on the same sample
| Threshold | Flagged for review | Urgent found | False alarms | Urgent missed |
|---|---|---|---|---|
| 0.90 | 40 | 36 | 4 | 64 |
| 0.70 | 100 | 70 | 30 | 30 |
| 0.40 | 220 | 90 | 130 | 10 |
At 0.90, 36 of 40 flags are genuinely urgent: precision is 90%. But only 36 of the 100 urgent cases are found, giving 36% recall. At 0.70, both precision and recall are 70%. At 0.40, recall reaches 90%, while precision falls to about 40.9%. The same classifier scores can support very different operating policies.
Those denominators deserve a place in a review meeting. “Ninety percent” could describe the precision of the first row or the recall of the last. Neither statement identifies the workload. Keep the counts next to the rates and record who resolved ambiguous labels, such as a routine delay that becomes urgent only when a customer deadline is known.
Document AI likewise evaluates predictions against labeled test data and distinguishes precision, recall and below-threshold misses. Its field-level metrics are useful for extraction, but they do not supply a whole-business review policy. For message routing, define and label the message-level outcome being evaluated. Google Document AI: evaluation labels and threshold effects
Put review minutes beside the confusion counts
Assume each flagged message takes four minutes to review and the desk has 180 minutes available for this queue during the shift. The first threshold needs 40 × 4 = 160 minutes. The second needs 400 minutes. The third needs 880 minutes. These are workload estimates under an equal-duration assumption, not service-time measurements.
| Threshold | Review minutes | Capacity difference | Unfinished cases if only 45 are reviewed |
|---|---|---|---|
| 0.90 | 160 | 20 minutes spare | 0 |
| 0.70 | 400 | 220 minutes short | 55 |
| 0.40 | 880 | 700 minutes short | 175 |
The 0.90 policy fits this average budget but leaves 64 urgent cases in normal work. I would not call it acceptable merely because the queue clears. If the team’s agreed limit were ten missed urgent cases on this sample, only the 0.40 row would meet that limit, and it would still exceed available capacity. None of the three policies would satisfy both constraints.
That result should change the pilot plan. The team could narrow the first release to a better-performing message type, remove unnecessary review steps, or allocate more review time. Each option needs a fresh check. Raising the threshold until the dashboard turns green would hide the unresolved error requirement.
Average minutes also conceal bursts. Forty flags arriving near a departure cutoff create a different queue from forty spread through a shift. Record arrival times, review durations, oldest unresolved urgent case and coverage during breaks. Reserve headroom before treating a daily total as proof of a workable service level.
Check calibration without treating it as permission
A calibrated probability has an empirical interpretation across comparable predictions. Scikit-learn describes checking predicted probability bins against observed positive frequencies. A score near 0.8 is not a guarantee about one shipment, and a good calibration plot on one population may not transfer to a new language or trade lane. Scikit-learn: probability calibration and reliability diagrams
For this pilot, I would inspect bins separately for short English updates, multilingual messages and long forwarded chains. Show the sample size in every bin. Twenty apparently clean examples provide weak evidence for an uncommon failure. Keep an explicit route for unsupported formats and missing shipment context instead of assigning them a confident normal label.
Select on validation data, then test the frozen policy
Use a separate validation set to choose the threshold and keep a final test set untouched until the policy is fixed. Scikit-learn warns against training a classifier and tuning its threshold on the same data. Repeatedly inspecting a final test set while adjusting rules also turns that set into part of the development process. Scikit-learn: avoid threshold-tuning leakage
Freeze the model version, prompt or feature configuration, threshold, fallback rules and review instructions together. Then compare the actual urgent cases found, misses, review minutes and oldest unresolved case on unseen work. A model upgrade or a changed message mix should trigger another evaluation rather than inherit the old threshold by habit.
Sample the normal queue as well as the flags. Reviewing only positive predictions cannot reveal how many urgent cases the model missed. Have people label that audit sample without seeing the model score first where practical, and preserve disagreements for adjudication. Reviewers make mistakes too; human review is a workflow to evaluate, not a perfect ground truth generator.
The earlier classifier guide explains the interfaces behind bounded AI judgments. This follow-up supplies a decision sheet: counts, available minutes and an explicit condition under which the team should withhold rollout. Read: AI classifiers and business decisions
