The optimization said Driver Reyes was the right choice. The algorithm scored the load against every driver in the fleet, ranked them by availability, distance, and HOS (hours of service, the FMCSA's daily and weekly driving limits under 49 CFR Part 395) margin, and Reyes came out first. What the optimization did not know, and could not have known from the data it had, was that Reyes's wife had just gone into premature labor the night before, that Reyes had texted the night dispatcher about it at 11:43 PM, that the night dispatcher had written "family matter, check with AM" on a sticky note that ended up under a dispatch log, and that when the morning dispatcher Sandra ran the optimization at 6:15, none of that existed in the TMS (transportation management system, the software platform that manages loads, drivers, and dispatch operations). Sandra committed Reyes to a 580-mile run before she knew. Reyes called from the fuel pump. The argument for optimization is a good argument: the algorithm can evaluate forty variables simultaneously, it does not get tired, it does not play favorites, and on a board with twenty loads and fifteen drivers, it finds combinations that a human dispatcher juggling phones will miss. The argument for the kill switch is equally good: the algorithm cannot see what is not in its data, it cannot weigh a human context it was never told about, it does not know what a seasoned dispatcher knows, and in freight, what the optimizer does not know can strand a driver, break a customer relationship, or create a compliance violation that shows up on the carrier's CSA (Compliance, Safety, Accountability, FMCSA's safety measurement system) score six weeks later. Both arguments are correct. This lesson is about building the written criteria that tell the dispatcher exactly when to stop the algorithm, step in, and make the call herself.

Why Optimization Fails: The Five Structural Blind Spots

A dispatch optimizer is not a poor piece of software when it misses something a veteran dispatcher would have caught. It is working exactly as designed, within the constraints of its data and its objective function. Understanding why it fails is the first step to knowing when to override it, because the failure modes are predictable. They are not random glitches; they are structural blind spots that appear reliably in certain categories of freight and operational situations.

Blind spot one: data that lives outside the TMS. The optimizer knows what is in its database. It does not know what the dispatcher knows: the verbal commitment made to the driver two weeks ago, the shipper who always runs two hours late, the receiver whose dock has been under construction since Monday, the driver who has been fighting a cold for three days and ran long yesterday. A dispatcher with five years on a specific network has hundreds of these facts in her head. None of them are in the TMS unless someone put them there, and in a real dispatch operation, most of them are not. The optimizer will produce a mathematically optimal match on the data it has and be completely wrong on the ground because the most important variable was never entered.

Blind spot two: objective function mismatch. An optimizer is built to maximize some measurable objective: minimized deadhead miles, maximized revenue per mile, minimized late deliveries, or some weighted combination. The problem is that the carrier's actual objective in any given moment may not match the optimizer's built-in objective. A dispatcher trying to protect a 15-year customer relationship may accept a worse match by every measurable metric to ensure that customer gets the right driver. A dispatcher trying to prevent a retention event for a top-performing driver who has been pushed hard for three weeks may deliberately give that driver an easy short-haul. Neither of those decisions is captured in the optimizer's objective function. The optimizer will flag them as suboptimal. The dispatcher knows they are exactly right.

Blind spot three: time-horizon myopia. An optimizer typically solves for the current dispatch window. It is very good at finding the best match for today's loads against today's drivers. It is poor at reasoning about what today's decisions do to the board three days from now: the driver who will be out of hours in a bad position if she takes this load today, the cluster of deliveries building up in a corridor the optimizer keeps routing drivers away from, the seasonal surge that is three days out and will punish any fleet that has moved drivers off their optimal corridors today. A veteran dispatcher with a mental map of the week thinks in time horizons the optimizer does not model. The override is not a rejection of the algorithm; it is the dispatcher adding the fourth dimension the optimizer is missing.

Blind spot four: safety signals in unstructured data. An ELD (electronic logging device, the FMCSA-mandated on-board recorder under 49 CFR Part 395.8) records hours compliantly. A DVIR (driver vehicle inspection report, required under 49 CFR Part 396.11) records defects. But neither of those records captures the dispatcher's observation that a driver who checked in at the terminal yesterday was notably quieter than usual, that the truck came in with more road dust than a normal run should produce, or that the driver mentioned he had not slept well in two nights running. These observations are the dispatcher's professional safety signal. The optimizer has no mechanism to receive them unless someone translates them into a data field, and the right response to a safety signal in unstructured form is not to create a data entry task; it is to override the match and check in with the driver.

Blind spot five: novel situations without training examples. An optimizer trained on historical load and driver data will perform well on loads that resemble its training distribution. When a novel situation arises, such as a new lane with no historical data, a shipper with an unusual requirement the carrier has never seen before, a route affected by an event the algorithm has not been trained on, or a regulatory change that came into effect after the model's training data ends, the optimizer's confidence scores are not trustworthy. The optimizer will produce a result as if the novel situation is just another standard case, and the result will be wrong in ways the dispatcher may not catch unless she knows to look for it.

The optimizer knows what is in its data. The dispatcher knows what is not. The kill criteria list is the formal agreement between them about when the dispatcher's knowledge wins.

The Kill-Criteria List: Twelve Situations That Require a Human Override

What follows is a written kill-criteria list. These are the specific situations in which a dispatcher should stop the optimizer's recommendation from being committed without direct human review and decision. The list is drawn from the five structural blind spots and from the categories of freight-specific operational failure that recurring dispatch incidents actually show up in. Every carrier should adapt this list to its specific operations, but the twelve categories below represent the baseline that any general freight carrier should maintain.

Kill criterion 1: any driver communication in the 12 hours preceding the dispatch that has not been entered in the TMS. If a driver has communicated with any member of the ops team about a personal matter, a vehicle concern, a fatigue issue, or a schedule change, and that communication has not been logged in the TMS as a driver status note, the optimizer does not know about it and should not be trusted to assign that driver until the dispatcher has reviewed the communication and made a judgment call. This is the Reyes scenario. The fix is both a kill criterion and an operational procedure: dispatchers should log all substantive driver communications in the TMS within four hours of receipt. The kill criterion protects the period before the log is updated.

Kill criterion 2: any load for a shipper or receiver with documented reliability issues not reflected in the current TMS record. If the dispatcher knows from experience that a specific shipper routinely adds 90 minutes to the standard dock time, or that a specific receiver's appointment window is effectively meaningless because they load by their own schedule regardless of appointment, the optimizer's HOS margin calculations for those loads are wrong. The dispatcher should not commit the optimizer's recommendation until she has manually adjusted the time estimate for the known facility behavior. The correction protocol is to update the TMS facility record with the actual historical dock times; the kill criterion protects loads at facilities where that update has not yet been made.

Kill criterion 3: any driver who has logged more than 55 driving hours in the current 8-day period. The legal maximum under FMCSA HOS rules is 60 hours in 7 days or 70 hours in 8 days (per 49 CFR Part 395.3). A driver at 55 hours in 8 days is not yet over the limit, but she is close enough that any unexpected delay on the next load puts her at risk of a violation, and the optimizer's planning horizon does not account for probability of delay. The dispatcher should review the next assignment for any driver in this HOS band and confirm that the load has a comfortable margin, not merely a compliant one.

Kill criterion 4: any load where the optimizer's proposed route deviates from the carrier's established routing for the lane by more than 20 miles without a documented reason. Route optimization algorithms occasionally find paths that are mathematically shorter by distance or time but that miss context the dispatcher has about road conditions, carrier-specific route restrictions, or customer requirements for delivery sequence. A route deviation flag should trigger a dispatcher review of the proposed route against the carrier's standard routing table before commitment.

Kill criterion 5: any HOS margin of less than 45 minutes after projected completion of the load including dock time. An optimizer set to maximize utilization will propose matches that are technically compliant with a small margin. The dispatcher's override criterion is different from the compliance criterion. Legally compliant is not the same as operationally safe. A load that leaves a driver with 22 minutes of HOS after delivery and dock time is a load that breaks the moment anything goes slightly wrong: a construction delay, a longer dock wait than projected, a missed turn that adds 15 minutes. The dispatcher should not commit any load with less than 45 minutes of margin after projected completion, regardless of what the optimizer says is legal.

Kill criterion 6: any situation involving a driver who has expressed any concern about the load, the route, or their own condition, regardless of their logged HOS availability. A driver's logged HOS availability is a floor, not a ceiling. The ELD says what the rules allow. The driver's professional self-report about their condition is also data, and it is data the dispatcher has a legal and moral obligation to act on. Under FMCSA regulations, a carrier cannot coerce a driver to violate HOS rules (49 CFR Part 392.1), and dispatching a driver who has expressed fatigue or concern over their own objection is a compliance risk as well as a safety one. Any expressed concern, even a casual mention, triggers the kill criterion: the dispatcher reviews the situation directly with the driver before committing the load.

Kill criterion 7: any load assigned to a driver within 36 hours of the driver returning from a 34-hour restart if the driver has not explicitly confirmed availability for the next run. A 34-hour restart resets the weekly HOS clock, but it is not a guarantee the driver is rested and ready. The restart window is legally a minimum; some drivers use it fully and come back fresh, others do not sleep through it. The optimizer will see the reset hours and immediately evaluate the driver as fully available. The kill criterion requires dispatcher confirmation with the driver before the first post-restart assignment is committed.

Kill criterion 8: any load involving a hazardous materials requirement, an oversize or overweight permit, or a special customer requirement not present in the standard load template. The optimizer may correctly match the driver's equipment type and HOS but miss the special requirement if it is not fully coded in the load tender fields. A hazmat load (for which the driver must hold the appropriate CDL endorsement) that is booked with a driver who does not have the endorsement is a compliance event from the moment of dispatch. Any load with a special requirement must be reviewed by the dispatcher against the driver's actual credentials, not just the optimizer's equipment-type match.

Kill criterion 9: any load where the optimizer's recommendation involves routing a driver through a weather event that was not in the system at the time the optimization ran. Weather changes faster than optimization cycles. An optimization that ran at 6:00 AM may not reflect the ice storm advisory issued at 7:15 AM. The dispatcher must maintain a habit of checking weather for any committed run before the driver departs and applying a kill override if conditions on the proposed route have deteriorated materially since the optimization was run.

Kill criterion 10: any customer where the dispatcher has knowledge of a relationship issue that is not reflected in the TMS. A shipper who is actively evaluating alternative carriers, a receiver who lodged a formal complaint two weeks ago that is still being resolved, a customer whose ops manager called the carrier's owner last week with concerns about service quality: these relationship signals should affect dispatch decisions in ways the optimizer cannot model. The dispatcher who knows about the relationship issue is the dispatcher who should review any load for that customer before the optimizer's recommendation is committed.

Kill criterion 11: any situation where the dispatcher has observed a driver behavioral change or safety signal in the preceding 72 hours that has not been documented in the TMS. This is the unstructured safety signal blind spot translated into an operational rule. If the dispatcher has noticed anything, a change in a driver's communication pattern, a comment about not sleeping, an unusually short check-in call that would normally be longer, the dispatcher's professional observation is safety-relevant data. The optimizer cannot see it. The kill criterion requires the dispatcher to check in with the driver directly before committing any load to that driver in the relevant period.

Kill criterion 12: any first booking on a new lane, with a new shipper, or using new equipment type that the optimizer has not seen in its training data. Novel situations are exactly where the optimizer's confidence is least warranted. When the carrier wins a new lane, signs a new shipper account, or puts a new equipment type on the board, the first few dispatches on that configuration should be reviewed manually by the dispatcher before commitment. The optimizer will produce a result, but without historical data on the new situation, that result is an extrapolation from similar historical patterns, not a validated recommendation. The dispatcher's review is the validation step for novel configurations.

The Override Log: Making the Kill Criteria Defensible

A kill-criteria list is not useful if overrides are invisible. Every time a dispatcher overrides the optimizer's recommendation, the override must be logged: what the optimizer recommended, what the dispatcher did instead, and why. This log is not a bureaucratic exercise. It serves three operational functions that a well-run fleet cannot afford to skip.

Function one: accountability.** The dispatcher who commits a load is the dispatcher who owns the decision. If the dispatcher overrides the optimizer and the override turns out to be wrong, the log records what the dispatcher knew and decided. If the dispatcher follows the optimizer into a situation the kill criteria should have caught, the log records that the kill criteria were not applied. In either case, the log is the evidence that lets the fleet manager and the compliance function understand what actually happened, rather than working backward from the outcome.

Function two: pattern recognition for criteria refinement. A fleet that logs overrides consistently will develop a data record of which kill criteria are most frequently triggered, which are triggered the most by specific loads or customers, and which override decisions turn out to be correct versus incorrect. This data drives calibration of the optimizer itself and refinement of the kill-criteria list. A kill criterion that is triggered twenty times a month and is correct eighteen of those times is a criterion worth keeping. A criterion that is triggered twice a month and is never validated by the outcome may need revision. Without the log, this analysis is impossible.

Function three: compliance protection. Under FMCSA regulations, the carrier is responsible for its dispatching decisions. If a dispatch decision results in an HOS violation, a safety incident, or a CSA event, the carrier will need to demonstrate that it had a defensible dispatch process in place. An override log that shows the dispatcher applied the kill-criteria list, documented the reason for the override, and made a professional judgment call based on the available information is the carrier's protection. "The optimizer said so" is not a defense. "The dispatcher reviewed the optimizer's recommendation, applied the carrier's kill-criteria protocol, and documented the override" is a defense.

The override log should include: the load number, the optimizer's recommended driver and route, the kill criterion or criteria that triggered the review, the dispatcher's actual decision, the reason stated by the dispatcher, the time and date, and the outcome (noted when the load is complete). The log does not need to be elaborate. A structured note in the TMS load record, tagged with a standard override-review flag, is sufficient and creates a searchable record.

The Trust Calibration Question: When to Follow the Optimizer

The kill-criteria list defines when to override. The dispatcher's professional practice should also include an explicit answer to the reverse question: when to follow the optimizer's recommendation without a human review beyond the standard checklist. Without this answer, the kill criteria become an excuse for second-guessing every recommendation, which defeats the purpose of having an optimizer in the first place.

The general principle is: follow the optimizer when the load is standard, the driver is in a normal operating state, the data in the TMS is current and complete, and none of the twelve kill criteria apply. More specifically:

Follow the optimizer when: the load type, the lane, and the equipment match are all familiar configurations with strong historical performance data in the optimizer's training set; the driver's TMS record is current and all driver status communications from the past 24 hours have been logged; the HOS margin after projected completion is 60 minutes or more; the shipper and receiver have reliable performance data in the TMS reflecting realistic dock times; no kill criterion is triggered on review; and the route is within the carrier's established routing for the lane. Under these conditions, the optimizer is almost certainly finding a better match than a human dispatcher doing the same analysis manually would find, and overriding it without a kill-criteria trigger is not caution, it is inefficiency.

A dispatcher who trusts the optimizer within its competence range and overrides it within the kill-criteria range is not a dispatcher who has surrendered judgment to the algorithm. She is a dispatcher who has calibrated her judgment to be deployed where it adds the most value: in exactly the situations where the algorithm's structural blind spots make its recommendation unreliable. That calibration is what this level of the certification is about. At L3, the practitioner is not simply checking AI output. She is the last line of defense between the optimizer's output and the road, and she knows exactly what she is defending against.

Applying the Kill Criteria in a Mixed Fleet Context

As covered in the preceding lesson, 2026 freight dispatch increasingly involves mixed autonomous and human-driver operations. Aurora's 250,000-plus driverless miles are now bookable through McLeod TMS (transportation management system) for 1,200-plus fleets, and the mixed-fleet model adds a new category of optimizer output that deserves specific kill-criteria attention.

The optimizer's recommendation that a load should use an Aurora autonomous slot for the highway segment is subject to several kill criteria beyond the standard human-driver list:

Kill criterion for autonomous segments: ODD boundary uncertainty. If there is any active weather advisory, road closure, or infrastructure condition that could affect the autonomous vehicle's operational design domain (ODD) during the proposed run window, the dispatcher should not commit the autonomous segment without confirming current ODD status with the Aurora system. The optimizer may have been run before the advisory was issued. The ODD check is an additional step, not a replacement for the standard kill-criteria review.

Kill criterion for autonomous segments: transfer hub availability not confirmed. The optimizer may recommend a mixed-fleet run with a specific hub, but if the dispatcher has not received confirmation that the hub is operational for the load's time window (holidays, maintenance windows, and capacity constraints at specific hubs are real operational factors), the mixed-fleet recommendation should not be committed until hub availability is confirmed.

Kill criterion for autonomous segments: either human driver's HOS position falls below the 45-minute margin standard on their segment. The autonomous segment does not consume human HOS, but the first-mile and last-mile drivers do have HOS constraints. If either driver's segment, including hub time, falls below the 45-minute dispatcher margin standard, the kill criterion applies to the whole load even though the middle segment is autonomous.

Building the Kill-Criteria List into the Dispatch Workflow

A kill-criteria list that lives in a policy document and is reviewed annually is a compliance document. A kill-criteria list that is built into the dispatch workflow is a safety tool. The difference is in how it is operationalized.

The most effective integration is as a pre-commitment checklist in the TMS, surfaced to the dispatcher every time she is about to commit an optimizer recommendation. The checklist does not need to be long. It can be a single question set built from the twelve criteria: "Before committing this load, confirm: driver communication status logged? facility dock times current? HOS margin above 45 minutes? no active weather on route? no special requirement unchecked? no customer relationship flag?" A dispatcher who answers these six questions before every commit will catch the Reyes scenario before she hits the send button.

For carriers that cannot embed the checklist in the TMS, a laminated card at each dispatch workstation with the twelve criteria serves the same function, provided the dispatcher culture treats it as a real check and not a formality. The culture is the carrier's responsibility; the list is the tool.

Quarterly review of the override log against the kill-criteria list is the calibration practice that keeps the tool current. If a kill criterion has not been triggered in a quarter, that may mean the operations are running cleanly in that category, or it may mean the criterion is being skipped. The fleet manager's job is to know which.

Key Takeaways

• The dispatch optimizer has five structural blind spots: data that lives outside the TMS, objective function mismatch with the actual dispatch goal, time-horizon myopia beyond the current window, safety signals in unstructured data, and novel situations without training examples. These are predictable failure modes, not random errors.
• The kill-criteria list is the formal written agreement between the optimizer and the dispatcher about when human judgment wins. It protects the situations where the optimizer's structural blind spots make its recommendation unreliable.
• The twelve kill criteria cover: driver communications not in the TMS, facility reliability issues not in the record, drivers above 55 hours in the 8-day period, route deviations above 20 miles, HOS margin under 45 minutes at completion, driver self-reported fatigue or concern, post-restart confirmation gaps, loads with special requirements unchecked against credentials, route conditions changed since optimization ran, customer relationship signals not in the TMS, dispatcher-observed behavioral safety signals, and novel lanes or configurations without training data.
• Every override must be logged: what the optimizer recommended, what the dispatcher decided, why, and the outcome. The override log serves accountability, pattern recognition for criteria refinement, and compliance protection in FMCSA reviews and shipper disputes.
• "The optimizer said so" is not a defense. "The dispatcher reviewed the recommendation, applied the kill-criteria protocol, and documented the override" is a defense.
• The kill criteria apply within defined conditions, and the trust calibration question is equally important: follow the optimizer when the load is standard, the driver data is current, all kill criteria pass, and the HOS margin is above 60 minutes. The dispatcher's judgment should be deployed where it adds the most value, not used to second-guess every recommendation.
• Mixed-fleet operations add three additional kill criteria for autonomous segments: ODD boundary uncertainty from active advisories, transfer hub availability not confirmed, and either human driver's segment falling below the 45-minute HOS margin standard.
• The kill-criteria list belongs in the dispatch workflow as a pre-commitment checklist, not in a policy document. A list that is reviewed annually is a compliance document. A list that is reviewed before every commit is a safety tool.