The route crosses itself twice and the driver has already resequenced it

Most sequences that look wrong are right, and the ones that are genuinely wrong look identical from the cab. The separation is mechanical: replay the plan leg by leg and, for each one, record which constraint was binding at the moment the solver committed to that order. Legs that come back carrying a reason — a window that closes at 12:30, a turn that is banned, a cage that has to come off last — are correct and are being argued about because nothing on the driver's screen says so. Legs that come back with no binding constraint at all are pure cost decisions, and those are the ones worth looking at.

The distinction matters because the two failures have opposite remedies. The first is fixed by explanation and stays fixed. The second is fixed by a longer search or a more honest travel-time matrix, and re-running the optimiser on the first kind produces the same sequence and a driver who now trusts it less. This is the point in routing, dispatch and optimisation where an engineering problem turns into a communication problem without anyone announcing the transition.

Replaying the route with a reason on every leg

The replay is a checker, not a solver. Take the published sequence, walk it forwards accumulating clock time and load, and at each transition record what would have gone wrong had the next-nearest unvisited stop been served instead. Four fields per leg are enough: the reason class, the constraint that bound, the value that bound it, and the penalty the alternative would have incurred.

A map draws distance. Nearly everything that decides a delivery sequence is invisible on one.

Asymmetry: the property that makes a sensible map look mad

Travel time between two points is not the same in both directions, and in dense urban networks it is routinely not close. One-way systems, banned right turns, a central reservation, a bus gate: any of them can make the return leg twice the outbound. A matrix computed once and mirrored to halve the request count encodes an average of the two, which is a value that is wrong in both directions and wrong in a way that is invisible on a screen.

• Test it directly. Sample 25 stop pairs from a live route and request both directions. A median absolute difference above roughly 10 per cent means mirroring is materially distorting your plans, and in a historic town centre the figure is often far higher.
• Test time-dependence the same way. Request the same 25 pairs at 06:30 and at 08:15. A matrix built once at the wrong hour prices the whole afternoon incorrectly, and the tiering that fixes it without exhausting a provider quota is set out in building a travel-time matrix you can afford to rebuild every morning.
• Check the profile the matrix was built for. A matrix computed for a car and used to plan a rigid does not overestimate difficulty conservatively — it routes through roads the vehicle may not legally enter, and every leg is quietly optimistic.

Three tells that the sequence is genuinely bad

Once the replay is running, the genuinely bad legs identify themselves rather than being argued about. Three patterns account for nearly all of them.

1. Self-crossing legs with no reason class attached. A construction heuristic left to stand, or an improvement phase cut short, leaves crossings that a local-search move would have removed. Extend the search budget on that one instance and see whether the crossing survives; if it does not, the plan was rushed rather than constrained.
2. One stop sitting far outside its own cluster. Almost always a coordinate problem — a pin on the wrong side of a motorway, a postcode centroid, a unit number matched to the wrong building. Check the coordinate against the address before checking anything in the model.
3. The same leg is chosen every day and drivers reverse it every day. If the replay attaches a reason and the drivers still reverse it, the recorded constraint is wrong rather than the sequence — a receiving hour that changed two years ago, or a service time that assumes a bay the site closed.

When testing whether a driver's own order was genuinely faster, compare against their recorded trace rather than against your model — and treat the trace carefully. A stationary vehicle produces position noise that a naive comparison reads as travel, inflating the driver's apparent time, which is the failure mode described in a parked truck that keeps moving.

One line of text under each stop, and the argument stops

The deliverable from all of this is not a better plan. It is a sentence per stop on the driver's list, generated from the replay: "Before stop 41 — 41 closes at 12:30". "After stop 12 — cage order". "No turn from Mill Street". Short, specific, and derived from the constraint that actually bound. Drivers do not need the objective function; they need to know that somebody knew about the thing they can see out of the windscreen.

Loading order deserves its own treatment on that list, because it is the constraint drivers accept instantly and planners forget entirely. A plan that is feasible on weight and volume can still be physically impossible to unload in the order it specifies, and the modelling that avoids it is in modelling weight, volume, pallets and cages together.

What an explanation will not settle

• A constraint the driver knows is false. If the window on the screen is wrong, explaining it more clearly makes the plan less credible rather than more. Route the correction back into the stop record, with a name and a date attached.
• A desk that has already rebuilt the plan. Drivers resequencing and dispatchers resequencing are different symptoms with different causes, and the second is diagnosed by logging the edits rather than by annotating the legs.
• The question of who may deviate. An explanation surface makes deviation an informed choice, which is progress, but somebody still has to decide whether a driver may reorder a route and what happens to the promised windows when they do — the governance staged in putting an optimiser on a manual dispatch desk.
• Whether the plan was good. Explanation makes a plan legible, not correct. Keep measuring planned against actual, because a plan that is fully explained and consistently 20 minutes optimistic is still a plan nobody can keep.

Generating and shipping these annotations is a small, well-bounded piece of operations automation: a checker beside the solver, four fields per leg, one string rendered into the driver app. It is also the cheapest trust the plan will ever buy, and in most logistics and mobility rollouts it does more for adoption than another round of tuning.

• route optimisation
• driver apps
• sequencing
• explainability