ReassigningPolicy

Takes a task back from a vehicle when a materially better pairing has become available.

The capability the passive paradigm cannot express. There, a transporter belongs to the entity that seized it until the journey ends, so a cart three-quarters of the way to a far pickup goes on to it however good the alternative -- not because the movement machinery could not turn it round, but because there is no object whose business it would be to decide.

The threshold is what makes this usable rather than pathological. Without one, any improvement at all justifies a swap, and a fleet under load will churn: revoke, redirect, revoke again as the board shifts under it, with vehicles spending their time changing their minds. Requiring the saving to exceed a stated distance means a swap has to be worth making. Set it in the same units as the layout's own distances.

Only assignments whose load is not yet aboard are considered; once a vehicle has the load it finishes the delivery, which the assignment's own guard enforces rather than this policy remembering to check.

A stopped vehicle is taken off its task whatever the distances say

A vehicle that has broken down or run out of charge is no further from its pickup than it was -- having driven part of the way, it is usually nearer -- so a rule that compares distances never takes work back from it, however long it stands there. That is the wrong answer, and it is wrong silently: the load waits on a vehicle that is not coming while a healthy one sits idle.

So a stopped incumbent is treated as unable to collect at all, and any vehicle that can reach the pickup takes the task. FleetVehicle.isOutOfService is the test. The threshold does not apply, because the incumbent's cost is no longer a distance to compare against.

Being told is a separate matter from acting. Nothing inside the subsystem wakes the dispatcher when a vehicle stops, so this rule fires at the next pass rather than at the breakdown unless the model attaches ReconsiderOnInterruption.

The inner policy must rank pairings, not tasks

The default is a scoring policy over the feasible set, and that is not an arbitrary choice. NearestVehiclePolicy walks the tasks in selection-rule order and picks the nearest vehicle for each; with one vehicle and two tasks it therefore hands the first task in the queue whatever is free -- including the vehicle that was just taken off it. A re-tasking policy wrapped around a rule like that revokes and immediately re-awards the same pairing, does it again on the next pass, and accomplishes nothing but a rising revocation count.

A policy that ranks pairings has no such problem: it takes the globally best vehicle-and-task together, which after a revocation is the near task the revocation was made for. Anything supplied here should have that property, and the interaction is worth knowing about because the failure is silent -- the model runs, the loads are delivered, and only the revocation counter says something is wrong.

Parameters