Real-time re-optimization covers replacing the whole plan on disruption. This page covers the finer-grained controls: locking part of a resource’s tour in place while the engine re-plans the rest, and reserving a stop for exactly one resource without making it mandatory.
Locking a sequence: mode × assignment status
A resource’s state.mode (free/fixed) and each state.assignments[].status (assigned/fixed) combine as follows:
Live supervision as a tour progresses
Reflect a driver’s real progress with successive PUT /plans/{planId} calls: a begin assignment with the real departureTime, then stop assignments filled in with arrivalTime/beginTime/departureTime as they actually happen, a break inserted dynamically if needed. Keep mode: "free" so the engine can still plan what comes after, and give every pinned assignment status: "fixed" — "assigned" isn’t a valid combination with mode: "free":
Pinning a stop to exactly one resource (pattern “Isolate”)
forbiddenAssignment (see Real-time re-optimization) excludes a resource/stop pairing. There’s no dedicated field for the opposite — reserving a stop for exactly one resource. The workaround: give the resource a skills entry derived from its own id (for example skills: ["resource-12"]) and require it on the targeted order (requiredSkills: ["resource-12"]).
This is a strong bias, not a guarantee. Unlike state.assignments in fixed mode, the engine can still leave the stop unplanned if the assignment would hurt a higher-priority objective too much.
See also
