In this note
A shipment coordinator needs to know which deliveries deserve attention. Software could estimate the risk of delay, apply a rule to choose shipments for review, and prepare an explanation. Those are three different jobs. They don’t all need a language model.
I’d separate those jobs before choosing a model. Code can apply a known routing rule. A predictive model might supply the risk estimate, if it performs well enough on this work. A language model might help explain the evidence after the route is settled.
We’ll follow a hypothetical shipment into the review queue to see that split. The local program behind the example uses supplied scores and explanations rather than calling real models. The case below explains its route. You can map your own decisions with the downloadable worksheet; this page does not supply the program.
Write the decision, not the feature name
For the shipment example, the job is to decide which in-transit shipments a coordinator should review. The software prepares the case. The coordinator decides whether to intervene; the software cannot reroute a truck or promise a new date.
Watch a coordinator handle a few cases you’re allowed to inspect, including one returned for correction. What did they need to know? Which rule settled the decision? What did they do when information was missing? Here, the software’s job ends when it prepares the review case. The coordinator’s decision and the delivery happen later.
Before automating a step, ask whether it should exist at all. A duplicate check caused by two disconnected records might be cheaper to remove by repairing the data flow. Required approvals stay in place until their owner authorizes a change.
Match the mechanism to the job
| Job | Candidate and evidence needed |
|---|---|
| Apply a fixed rule or calculate a number | Code, a query, or a rules engine. Test the allowed inputs, edge cases, and policy revision. |
| Choose a plan under stated constraints | An optimizer. Check that its plan is feasible and that its objective matches the owner’s priorities. |
| Estimate risk or rank likely outcomes | Statistics or a predictive model. Compare with a simple baseline using permitted labels and errors that matter to the workflow. |
| Find a fact or policy | A structured source query or document retrieval. Check source authority, revision, freshness, and whether the evidence answers the question. |
| Interpret an unclear message or document | A language-model call with a defined job. Check the extracted meaning, unsupported claims, and cases it should send to a person. |
| Choose the next step from feedback | A bounded agent workflow, if the path genuinely varies. Set tool limits, stop rules, persistent state, and result checks. |
| Make a consequential judgment with weak evidence | An accountable person. Give them the evidence and enough time to accept, reject, or defer. |
You won’t need every row. Compare the plausible options on the same cases, with the same access and action limits. Include the time people spend checking mistakes. A cheap prediction that floods the review queue can cost more than the current process.
Agree which mistakes matter before running the comparison. A missed risky shipment and an unnecessary review have different costs. Check both against independently confirmed outcomes, including difficult shipments and cases with missing information. Keep the current queue as a baseline, and check how many cases the coordinator can review without delaying urgent work.
Follow one shipment through the split
In the local shipment example, the supplied risk score is 0.91 and the shipment value is $24,000. A fixed teaching policy requires review when the score is at least 0.80 and value is at least $10,000. Those numbers are hypothetical test inputs and thresholds, not recommended business defaults. A score of 0.91 also does not establish a calibrated 91% chance of delay.
- Read current evidenceCheck what the requester may read, which customer the shipment belongs to, its identity, and whether the record is recent enough.
- Obtain a risk scoreCheck the score’s range and model version, and that it uses this version of the shipment evidence.
- Apply the routing ruleCode checks the score and value thresholds. Lower-risk cases need no explanation call.
- Prepare the review caseCheck permission to save a review case and the remaining budget. Use an optional explanation or a fixed evidence summary.
- Stop at review readySave the case without changing the shipment. The coordinator’s later decision is outside this implementation.
Code decides the route before asking for an explanation. The explanation helps the coordinator read the case; it cannot change who gets reviewed. If it fails, a fixed summary keeps the required case moving. Low-risk shipments skip both the explanation and case creation.
In the teaching implementation, both the score and explanation are supplied test inputs. The program stops at “review ready”; it records no coordinator decision or shipment-system confirmation. Its local checks exercise the routing code without establishing whether a predictor or generated explanation would help a real coordinator.
Test a boundary without claiming the whole outcome
The program has ten local tests. They include stale evidence stopping before scoring, an out-of-range score stopping before a case is created, a customer-account mismatch denying the read, explanation failure using a fixed summary, and repeated requests with the same operation ID reusing one staged case. They also check that explanation text requesting a different route cannot override the routing rule.
The tests cover a small in-memory program. They leave storage, concurrent requests, and production recovery untested. They also check only the explanation’s shape and length. Before using generated explanations, check their claims against the source and watch whether they help reviewers.
A better explanation gets no extra permission
Now consider a different job: understanding a customer’s request to change a delivery date. A model can propose that “Friday afternoon would be better” means a request for a Friday slot. Software still needs to check which order the caller may access, whether that slot exists, and whether the cutoff has passed. Ask the customer to clarify when the intended date remains uncertain.
If an exception requires approval, enforce it where the change happens. A confident interpretation cannot waive the cutoff. Bind approval to the exact proposed change, check the current order again, and verify the recorded date after an authorized update. If confirmation is missing, report the uncertainty rather than saying it succeeded.
Bring a step map to the next design review
Pick one workflow and write a row for each decision. What information goes in? What should come out? Who or what could do the job, and how would you catch a wrong answer? Include what each step may do and where the case goes if it fails. The worksheet has room for the details.
Test one choice first. For shipment routing, compare the current queue, a simple rule, and a predictive score on cases kept out of development and tuning. Set the thresholds before looking at those results. Count missed risky shipments and unnecessary reviews, then compare review time, response time, and full cost. Use that evidence to decide which components to keep.