A route can fit inside a vehicle and still arrive too late. That sounds obvious, but it exposes a useful question for any planner: what exactly does the word feasible promise?
I reviewed the routing module in HyperFleet, my private .NET 10 fleet-orchestration prototype. It builds a delivery order from parcel locations, vehicle limits, and estimated travel times. Reading the implementation beside its tests revealed a boundary worth making explicit: the prototype accounts for delivery windows when it calculates arrival times, but its final feasibility flag does not validate those windows.
Can the estimate meet the window?
With no unassigned parcel, the current prototype can return IsFeasible = truewhile this estimated stop is late.
What the prototype calculates
The solver first walks through parcels in request order. It assigns a parcel if its weight and volume fit the remaining vehicle capacity and, when needed, the vehicle has refrigeration. Parcels that fail those checks are returned as unassigned.
For the route, it repeatedly selects the remaining parcel with the shortest estimated distance from the current location. Distance starts with the great-circle distance between coordinates and is multiplied by a fixed 1.25 road factor. Travel time uses a fixed average speed of 45 km/h, and every delivery adds five minutes of service time. If a vehicle reaches a stop before its earliest delivery time, the estimate waits until that window opens.
Those are understandable prototype assumptions. They are also estimates: the solver does not use a road network, live traffic, or time-dependent speeds. More importantly, it does not reject a stop whose estimated arrival is after LatestDeliveryUtc. The code comment says a late stop is penalized, but the selection path only compares distance; it does not calculate or apply a lateness penalty.
A small example makes the contract visible
Suppose a van leaves at 08:00. A delivery is 20 km away in a straight line, and the prototype’s road factor turns that into 25 estimated kilometres. At 45 km/h, the rounded travel estimate is 33 minutes. If the delivery window closes at 08:20, the estimate arrives at 08:33.
That is a useful warning from the model: under its assumptions, the stop is late. But if the parcel fits the vehicle and no parcel is left unassigned, the current result can still set IsFeasible to true. That flag is derived from the unassigned-parcel count, which currently reflects capacity and refrigeration checks.
The distinction matters to the next system that consumes the result. A dispatcher UI, an API client, or a future optimizer may treat IsFeasible as a promise that all constraints passed. If it actually means “all requested parcels passed the current vehicle checks,” the name carries more certainty than the implementation provides.
Route improvement must preserve the schedule
For routes with at least four stops, the solver applies a bounded 2-opt pass to shorten the distance. It reverses a segment when the estimated distance improves. The pass updates the route’s distance, but it does not replay the schedule afterward: stop arrival times, the total duration, and the sequence numbers remain from the earlier ordering.
That makes route quality and schedule validity separate questions. A shorter ordering may be a better geometric route, but its arrival estimates need to be recalculated in that new order before the result can say whether the delivery windows still hold. Optimization should be followed by validation against the same constraints that define success.
What the tests establish
The routing unit tests cover a route whose parcels fit, a weight overflow that leaves a parcel unassigned, and a refrigerated parcel assigned to a vehicle without refrigeration. The happy-path test checks that four stops are returned, the route has a positive distance and duration, and the reported sequence numbers increase.
It does not assert that each EstimatedArrivalUtc is at or before its LatestDeliveryUtc. There is also no routing test for a late arrival or for preserving delivery windows after the 2-opt reorder. The latest HyperFleet CI run on the reviewed revision passed restore, Release build, and the .NET test suite; that is good evidence for the tested paths, not proof of an untested time-window guarantee.
What I would change next
I would make the result contract explicit before making the route algorithm more ambitious:
- Return constraint outcomes per stop, including the estimated arrival, window end, and any lateness, instead of hiding them behind one Boolean.
- Recalculate arrival times and stop sequence after every route reorder, then run one final feasibility check.
- Add deterministic tests for a late stop, a stop that opens later than the vehicle arrives, and a 2-opt change that alters the schedule.
- Replace the fixed road factor and average speed with a travel-time source whose limits and freshness are visible to the caller.
Those steps would let a caller distinguish “the solver produced an order” from “the plan satisfies the constraints we checked.” In this revision, IsFeasible reports only capacity and refrigeration checks: it can remain true when the estimate reaches a stop at 08:33 after its 08:20 window closes. Until arrivals are recalculated after 2-opt and every window is checked, a caller should treat the result as an ordered route, not a delivery plan. A production dispatch system would still need stronger evidence around real road times, service durations, failure handling, and operational data.
The 08:33 example is hand-calculated from the prototype’s fixed road factor and speed; it is not a benchmark or a real dispatch result. HyperFleet remains a private prototype. For related examples of making evidence boundaries visible, read how Aurora handles synthetic telemetry and how Sentinel-DB treats SQL it cannot classify.