What makes this vertical distinctive
- Reconfigurable cold compartment — a truck’s compartment runs in ambient or frozen mode, one at a time: it never carries both loads at once, and can switch modes once the previous load is delivered.
- Trusted-keychain deliveries — a set of key-gated stops is kept to a single driver for the day, not split across whoever has room.
- Preferred zones — drivers are softly tied to their usual sector, pulled elsewhere only once it’s covered.
- Predictive traffic — forecast travel time is baked into the route calculation itself.
Combined example
Reconfigurable cold compartment
truck-1.capacities and driver-1.capacities both carry ambiant and frozen as two independent dimensions. An atLeastOneValidCapacity constraint scoped to bi-temperature-tagged resources requires at least one of the two to stay at zero at every stop: at any point of its tour, each truck carries only ambient or only frozen goods, never a mix, and it can switch from one to the other once the previous load is delivered. The tag decides which resources the rule covers: a resource without the bi-temperature tag is outside the rule and can carry both at once. The declared capacities only set how much of each kind a truck can carry, and a resource that doesn’t declare a capacity has no limit on it, which is why every truck in this example declares both. This is a related but distinct pattern from Multi-compartment vehicles: that guide’s atLeastOneConstraint picks one whole setup for the entire tour, while this gate is checked stop by stop through an ordinary capacities mutual-exclusion.
Trusted-keychain deliveries
order-keychain-0/-1 share the tag keychain:trusted-set-1. A globalConstraints entry of type maxCumulatedCost gives every driver-tagged resource a cost on the stops of that set: costCoeff: 1 counts each keychain stop the resource visits, and overcostFloor: 1 with overcostCoeff: 0 stops the count after the first one. Each driver therefore costs 1 as soon as it takes a keychain stop, and maximum: 1 across the whole fleet leaves room for a single driver on the set. Every resource in this example carries driver, because the constraint only counts resources with the tag it targets and a wildcard isn’t accepted. If no single driver can reach every stop of the set in time, the extra stops stay unplanned, in unaffectedStopIds, rather than going to a second driver (see Handling infeasibility). See Constraints catalog.
Preferred zones
truck-1.preferredStopTags: ["zone:usual-sector-7"] is matched against the same tag on stop-afternoon-delivery — a soft pull toward the truck’s usual sector, scored through maximizePreferredStops rather than enforced as a hard rule. It’s the same preferredStopTags mechanism Driver skills and qualifications documents for a skill preference, applied here to a zone instead.
Predictive traffic
truck-1.vehicleProfile.withTraffic: true makes the engine use forecast travel times for this truck’s legs rather than free-flow distances.
Full payload
Full payload — ready to submit as POST /plans
Full payload — ready to submit as POST /plans
The preceding example isolates the four mechanisms this vertical needs; this expands it to the scale of a real working day — a full fleet schedule (
workingTimeWindow, departure, arrival), the complete objectives list, and enough orders to look like an actual route rather than a minimal illustration. Submit it as-is via POST /plans — the service assigns the plan’s id, so don’t include one of your own. Its datetimes are local times, read in the plan’s tz (Europe/Paris); see Dates and time zones.See also
- Modeling advanced constraints — the related whole-tour compartment-setup pattern.
- Modeling advanced constraints —
preferredStopTags, the soft mechanism behind zone preference. - Data model — the full
additionalConstraintsandglobalConstraintscatalog.