Vocabulary mapping - Kardinal Route Optimization API

If you’ve worked with another routing or optimization tool, the underlying problem is familiar — this maps the vocabulary the field generally uses to what it’s actually called in Kardinal’s Route Optimization API.

Generic vehicle-routing term	Kardinal equivalent
Vehicle Routing Problem (VRP)	A `Plan` — `resources`, `orders`, and any plan-level constraints or objectives. See Data model.
Route / trip	A `tour` in the solution (`item.tours[]`). See Glossary.
Depot	Not a first-class object — a resource’s `departure`/`arrival` position. See Depot vs. position.
Multi-depot VRP	Multiple resources with different `departure`/`arrival` positions inside the same `Plan` — not one `Plan` per depot. See Depot vs. position.
Hard time windows	`authorizedTimeWindows` — outside of it, the stop can’t be planned at all. See Hard vs soft constraints.
Soft time windows / lateness penalty	`preferredTimeWindows`, tracked by the `minimizeDelay` objective. See Hard vs soft constraints.
Capacitated VRP (CVRP)	`capacities` — free-form named dimensions declared on both resources and stops. See Capacities.
VRP with Pickup and Delivery (VRPPD)	Pickup- and delivery-kind stops inside the same `Order`, in array order. See Order, stop.
Skill-based / heterogeneous fleet routing	`requiredSkills` (hard match) or `preferredStopTags` with `maximizePreferredStops` (soft preference). See Skills and assignments.
Multi-trip VRP (vehicle reloads mid-shift)	The depot-return pattern in Multi-trip tours — no dedicated field, built from `capacities` and stop `kind`.
Precedence constraints	Strict: the stops of one `Order` keep their array order, on one vehicle (see Order, stop). Between different orders the engine has no hard precedence; you can pin a sequence yourself with fixed assignments. Soft: the `maximizePrecedences` objective, with tagged pairs counted inside one tour (see maximizePrecedences).
Cost / objective function	An ordered `objectives` list, optimized in strict lexicographic priority — not a single weighted score. See Objectives and how they’re ranked.
Dynamic / live re-optimization	Submitting the complete plan again under the same `id` (`PUT /plans/{planId}`) — the engine updates the existing solution instead of solving from scratch. See Real-time re-optimization.

See also

Glossary — the full list of Kardinal-specific terms.
Data model — an overview of Resource, Order, and Stop, each linking to its schema in the API reference.
How the optimization engine works — objectives and the optimization loop.