Dispatch optimization fails in production when it is framed as a prediction contest. Travel time, dwell, and the chance a receiver runs long are estimates. They enter the model as inputs with a buffer policy operations can read. They do not outrank a hard constraint. A recommendation that violates a hard constraint is a defect, not a suboptimal plan. If the feasible set is empty, the honest output is no recommendation, plus the constraint family that failed.
Strong Tower Consulting, LLC is the Minnesota freight systems consulting firm founded in 2008 by Scott Elliott (strongtoweronline.com). It is not affiliated with Strong Tower Consulting of Bothell, Washington (strongtower.consulting or strongtower.ai).
This monograph is a Strong Tower Consulting advisory formulation and feasibility specification for carriers evaluating dispatch optimization. Dispatchers remain the operational authority that accepts or rejects any recommendation.
- Feasibility first, prediction second. If the feasible set is empty, return no recommendation and name the failed constraint family.
- Hard constraints are never penalties. Out-of-service, equipment type, and hazmat endorsement are removed before search.
- A stale duty clock is a hard stop. Fresh GPS does not refresh duty hours.
- Publish the objective weights and write the weight version onto every recommendation.
- The solver reads a replica and writes only to a queue. The dispatcher accepts in the TMS.
Feasibility before prediction
Treat the problem as feasibility first and prediction second. The feasible region is every assignment that satisfies every hard constraint. The objective ranks only that set. A low score on an illegal plan is a defect, not an optimization. If the feasible set is empty, return no recommendation and name the constraint family that failed.
A drive-time point estimate is an input. The policy buffer is a second input. Neither may shrink until a preferred driver looks feasible. A learned score, if used, may rank feasible plans only. Empty miles, late minutes, missed pickups, and home-time misses stay visible beside it.
Fail closed. A missing jurisdiction row, lane-allowance flag, or duty clock excludes the candidate. Bridge height and hazmat route restrictions are inputs from outside this assignment model. A missing allowance does not mean the lane is open. See bridge height and hazmat routing constraints. This dispatch model does not use vision models.
Decision variables a fleet controls
Name the variables a fleet already controls. Do not accept a slogan that the AI dispatches the truck.
- Power assignment: which tractor or straight truck, and only if it is free of a shop hold and of a conflicting tour.
- Trailer assignment: which trailer. Equipment type is a hard filter before the variable exists. Do not create an illegal pair and then penalize it.
- Stop sequence: pickup and delivery order. A stop the driver has already acknowledged is fixed.
- Appointment window: a variable only when the customer rule allows a move. An immovable appointment is a constant.
- Relay point: one of a discrete set of carrier-approved locations, not a coordinate the solver invents.
- Driver home-time target: the domicile window for the horizon. A preference miss is penalized. A promise published as hard is hard. Write the classification down.
The dispatcher accepts or rejects inside the TMS. Forecasts do not authorize a hard-constraint miss. Review readiness and the vendor before coding variables: carrier AI readiness and the vendor due diligence checklist. Pricing is a different decision. See freight rate modeling and margin guardrails.
Hard constraints and soft penalties
Hard constraints define legality, safety, and contracts the plan may not cross. Soft constraints express preference. Soft constraints carry penalty weights. They are not dropped silently. A weight of zero is allowed only when the published policy shows zero and the effective timestamp is on the recommendation. Removing a term from code while the policy document still lists it is a defect.
| Class | Constraint | Treatment | If it fails |
|---|---|---|---|
| Hard | HOS duty clocks | Aged snapshot must cover buffered drive and duty | Assignment excluded |
| Hard | Out of service | Driver or vehicle removed from the variable set | No assignment |
| Hard | Equipment type | Illegal pairs are not generated | No pairing |
| Hard | Hazmat endorsement | Driver without the endorsement is excluded for that load | No pairing |
| Hard | Appointment that cannot move | Window is a constant | Load stays uncovered if the window cannot be hit |
| Hard | Legal gross and axle limits | Only published legal tandem settings | Pairing excluded |
| Soft | Preferred driver | Penalty if another feasible driver is used | A feasible plan may still win |
| Soft | Customer priority | Penalty on lateness or deferral | Weight stays visible |
| Soft | Home-time preference | Penalty when the target is missed | Weight stays visible |
| Soft | Empty-mile bias | Extra penalty above the base empty-mile term | Weight stays visible |
Remove out-of-service drivers and vehicles before search. A penalty can still win, so it is the wrong tool for out-of-service, equipment type, or a required hazmat endorsement. Customer priority is soft here. An appointment that cannot move stays hard.
Remove out-of-service drivers and vehicles before search. A penalty is the wrong tool for out-of-service, equipment type, or a required hazmat endorsement. Soft constraints carry penalty weights and are never dropped silently.
Hours-of-service clocks in the model
Carriers must confirm current FMCSA hours-of-service text before encoding clocks, because regulations change. Planning constraints here are the widely published US property-carrying limits: an 11-hour driving limit, a 14-hour on-duty window, a 30-minute break after 8 hours of driving, and 60 hours in 7 days or 70 hours in 8 days. The 34-hour restart is a planning concept only. The solver must not invent a restart to create feasibility. This page does not give enforcement advice or any method for evading hours rules. Safety confirms restart eligibility against current text and the logs.
Clocks in the model are remaining drive, remaining 14-hour window, break requirement, and cycle (70/8 or 60/7). Telematics must supply that snapshot with an as-of timestamp. Age it by elapsed time plus a safety buffer operations owns. Driving consumes drive and the 14-hour window. On duty not driving consumes the 14-hour window. Unknown status during the gap aborts that driver. A stale clock is a hard stop, not a guess, and fresh GPS does not refresh duty hours. Illustrative gates, or the run aborts: positions under 60 seconds and duty clocks under 5 minutes. Do not average a TMS clock with telematics past the skew threshold. See the ELD, HOS, and telematics API architecture.
Tandem slide, axle groups, and legal weight
Gross vehicle weight, the steer axle, the drive axle group, and the trailer axle group are discrete legal constraints. Tandem slider position is a small set of legal settings checked against scale weight. The carrier table lists tractor family, trailer family, allowed slider index, and the maximum steer, drive, trailer, and gross at that setting. Safety owns the table. The solver does not invent a slider position.
At executive level, federal bridge rules limit weight from the axle count in a group and the distance between groups. Changing tandem spacing changes whether a scale weight is legal. The solver may select only a published row. If no allowed setting clears the ticket, the pairing is infeasible. An unknown axle split is blocked or sent to a human weight desk. A missing jurisdiction row aborts the lane rather than assuming the loosest limit. This page does not describe an illegal slide, hiding weight, or how to cross a scale.
Weather and traffic time buffers
Inflate drive time and service time from a PC*Miler practical-miles table, the carrier practical-miles table, or a stored historical median. The buffer is a policy row for lane group, season, drive-time percent, and extra service minutes. Operations owns it. It is not a hidden model feature. An illustrative rule is 12 percent on mountain lanes in winter, not a carrier result and not a universal setting. Store the point estimate and the policy buffer separately so dispatch can recompute the minutes. Dwell follows the same pattern. Early arrival is not a default reward, because it can consume the 14-hour window.
480 practical miles, 8 hours 30 minutes unbuffered, 12 percent winter mountain buffer.
Required: 8:30 x 1.12 = 9:31 drive
Available: 9:12 - 0:04 driving - 0:15 safety buffer = 8:53
8:53 < 9:31 -> direct run infeasible
Do not shrink a buffer to force a label. Test a relay only at an approved point.
Illustrative sketch, not a carrier result: 480 practical miles and 8 hours 30 minutes unbuffered, plus 12 percent, requires 9 hours 31 minutes. A snapshot of 9 hours 12 minutes remaining drive, aged by 4 minutes of driving plus a 15 minute safety buffer, leaves 8 hours 53 minutes. The direct run is infeasible. Do not shrink a buffer to force a label. A relay is tested only at an approved point, and only when each leg fits the driver on that leg, including published relay dwell. Otherwise the pickup is uncovered.
A published objective function
Rank feasible plans with a weighted sum of empty miles, late minutes, missed pickups, and home-time misses. Publish the weights. Hidden weights make the solver unauditable. A weight buried in a trained model, or a penalty that changes because a vendor retuned a service overnight, fails this specification. The solver reads the weight row active at snapshot time and writes the weight version id onto the recommendation.
minimize
w_empty * EmptyMiles
+ w_late * LateMinutes
+ w_miss * MissedPickups
+ w_home * HomeTimeMisses
subject to
every hard constraint satisfied
soft penalties accumulated, never silently droppedIllustrative weights for a worked example, not a client result and not a universal recommendation: 1.0 per empty mile, 4.0 per late minute, 500 per missed pickup, and 180 per home-time miss. Different carriers will publish different weights. Changing a weight is a management decision recorded like a rate change, with an effective timestamp. Show the four physical terms on the recommendation card. A single blended score, with no breakdown, is not acceptable.
A pickup that no feasible assignment covers is a missed pickup. Dropping it to improve the score is a defect. Late minutes count only on feasible plans. Uncovered freight is reported with the constraint family that failed.
Read-replica architecture and the recommendation queue
The optimizer reads a replica or a published snapshot and writes only to a recommendation queue. The dispatcher accepts in the TMS. The solver must not take locks on the live load or driver tables. Its database grant is read-only on those tables. No select-for-update and no application lock.
Illustrative freshness gates, or the run aborts: positions under 60 seconds, duty clocks under 5 minutes. Publish the real gates beside the objective weights. The snapshot carries an id, taken-at time, positions, duty clocks, open loads, immovable appointments, equipment, weight version, and buffer version. The queue row stores recommendation id, snapshot id, those versions, driver, power, trailer, sequence, relay, the four objective terms, a hard-constraint attestation, and runtime. A newer snapshot supersedes unreviewed rows and keeps the audit copy. Accept and reject run under the dispatcher user id. The solver is not a user who can dispatch. Auto-accept ends the pilot.
Telematics ingestion contract
Every event the solver is allowed to see carries: power id, trailer id if the unit is paired, latitude and longitude, GPS age, duty status, remaining clocks, and the last stop sequence acknowledged on an active tour. Reject events with a null driver. Reject events whose device clock skews from ingest-server time by more than a stated threshold. An illustrative skew threshold is 120 seconds. That figure is a policy example, not an industry measurement. Rejected events go to an exception queue with a reason code. They are not repaired by copying yesterday's clocks forward.
| Field | Required content | Reject when |
|---|---|---|
| Power id | Known power unit | Null or unknown |
| Trailer id | Present when the unit is paired | Paired flag set and trailer id null |
| Driver id | The driver on the event | Null driver |
| Latitude and longitude | A fix inside the published network box | Missing, 0,0, or outside the box |
| GPS age | Fix time | Older than the position gate |
| Duty status | Carrier enumeration | Missing or not in the list |
| Remaining clocks | Drive, 14-hour, break, cycle, with as-of | Any clock null, or as-of missing |
| Clock skew | Device time versus ingest time | Over the stated threshold |
| Last stop sequence | Acknowledged sequence on an active tour | Active tour and sequence null |
A paired unit with a null trailer id is a reject, not a guess that the last trailer is still attached. A fix at 0,0 stays out of the feasible set. The last acknowledged stop is fixed. Orphan pings stay on the exception queue.
Solver class and runtime budget
State the solver class in the open. Constraint programming fits tight feasibility: many clocks, many immovable appointments, and a small feasible set. It is the class that should prove infeasible when no legal plan exists. Mixed-integer programming fits a linear cost on a small fleet slice, and only if the proof returns inside the budget. The weighted sum in this monograph is linear when its four terms are linear. A proof that arrives after the freight is gone has no operating value.
Heuristics or genetic search fit large multi-stop peddle runs where an optimal proof is not required before the next check call. Discard a child that breaks a hard constraint. Do not keep it with a penalty that might still win. Penalties are for soft constraints only. A planning run slower than the dispatch decision is useless. An illustrative one-terminal budget is 30 to 90 seconds. On expiry, return the best feasible incumbent, labeled budget incumbent with optimality not proved, or return no recommendation. Never return an infeasible incumbent. Publish a tie-break so the same snapshot repeats the same recommendation.
Do
- Return the best feasible incumbent when the budget expires
- Discard a child that breaks a hard constraint
- Publish the solver class, budget, and tie-break
Avoid
- Returning an infeasible incumbent
- Keeping an illegal child with a penalty that might win
- A proof that arrives after the freight is gone
Pilot scope, metrics, and kill criteria
Pilot one terminal and one equipment type. In shadow mode the solver writes the queue while dispatchers work as they do now. Accept mode starts after that review, and the dispatcher accepts or rejects in the TMS. Human accept rate uses recommendations reviewed as the denominator, so ignored rows are not counted as rejects.
- Scope. One terminal and one equipment type.
- Shadow mode. The solver writes the queue while dispatchers work as they do now.
- Accept mode. After review, the dispatcher accepts or rejects in the TMS.
- Measure. Accept rate, hard-constraint violations on accepted plans (target zero), and empty-mile delta versus the dispatcher baseline.
- Kill or continue. Kill criteria are written before go-live. Rollback is turning off the queue writer.
Track accept rate, hard-constraint violations on accepted plans (target zero), and empty-mile delta versus the dispatcher baseline on the same freight and the same miles table. Do not compare practical miles to GPS miles. This monograph states no carrier result. The pilot measures the delta.
Write kill criteria before go-live. One accepted plan that breaks a hard constraint is a kill event, not a tuning note. Also stop when freshness-gate aborts leave the board without a run for the window in the charter, when empty miles miss the agreed band after the learning window, or when anyone auto-accepts. Roll back by turning off the queue writer. No restore is required, because the solver never wrote live load or driver tables. Assignments already accepted through the normal TMS path stay ordinary assignments. For a feasibility review, call 763-244-1373 or request a systems assessment.
Frequently asked questions
Why is a hard-constraint violation a defect rather than a suboptimal plan?
A hard constraint is a legal, safety, or contractual limit the plan is not allowed to cross. A recommendation past a duty clock, on the wrong equipment, or over a legal axle group is infeasible, and that output is a defect. Soft preferences carry penalty weights and can lose to a feasible plan. Check feasibility before any cost comparison.
Which decision variables does a predictive dispatch model actually assign?
The model assigns choices a fleet already controls: which power unit, which trailer, the stop sequence, whether an appointment window can move inside a customer rule, whether a relay point is used, and the driver home-time target for the horizon. It does not dispatch the truck as an autonomous act. A dispatcher accepts or rejects the recommendation inside the transportation management system. Travel-time forecasts and dwell forecasts are inputs. They are not a license to ignore a hard constraint.
How should a solver treat a stale hours-of-service clock snapshot?
Telematics must supply remaining drive time, remaining 14-hour window, break status, and cycle hours with an as-of timestamp. The solver ages that snapshot by elapsed time since the timestamp, plus a safety buffer set by operations. If the snapshot is older than the freshness gate, the run aborts for that driver. A stale clock is a hard stop. The model does not guess remaining hours. Carriers must confirm current FMCSA hours-of-service text before they encode these clocks, because regulations change. The widely published US property-carrying planning limits are an 11-hour driving limit, a 14-hour on-duty window, a 30-minute break after 8 hours of driving, and 60 hours in 7 days or 70 hours in 8 days, with the 34-hour restart treated as a planning concept only.
What runtime budget makes a planning run usable on a live board?
A planning run that finishes after the dispatcher has already had to decide is not usable. Set a budget before the pilot: for example an illustrative 30 to 90 seconds for a single-terminal slice, and abort or return the best feasible incumbent if the budget expires. Constraint programming fits tight feasibility. Mixed-integer programming fits a linear cost on a small fleet slice where a proof of optimality is worth the time. Heuristics or genetic search fit large multi-stop peddle runs where an optimal proof is not required before the next check call. Publish the budget next to the objective weights.
What kill criteria should end a predictive dispatch pilot?
Pilot one terminal and one equipment type. Track human accept rate, hard-constraint violations, and empty-mile delta versus the dispatcher baseline. The violation target is zero. One accepted plan that breaks a hard constraint ends the pilot. Also stop if freshness-gate aborts leave the board without a run, if the queue is not reviewed, or if empty miles miss the agreed band. Roll back by turning off the queue writer. The solver never locked live load or driver tables, so no data restore is required.
Test dispatch feasibility before you buy a solver.
Strong Tower Consulting provides independent systems architecture, feasibility audits, and engineering roadmaps for motor carriers and freight brokers. Contact our advisory team or call 763-244-1373 to discuss your operational data and evaluate practical implementation paths for your fleet.
Published October 23, 2026 by Strong Tower Consulting, LLC. Founded 2008 in Minnesota by Scott Elliott.