> ## Documentation Index
> Fetch the complete documentation index at: https://developers.kardinal.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Vocabulary mapping

> Translate the generic vehicle-routing terms you know from other tools, such as VRP, depot, time windows, or pickup and delivery, into Kardinal's own vocabulary.

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](/reference/data-model). |
| Route / trip | A `tour` in the solution (`item.tours[]`). See [Glossary](/reference/glossary). |
| Depot | Not a first-class object — a resource's `departure`/`arrival` position. See [Depot vs. position](/reference/data-model#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](/reference/data-model#depot-vs-position). |
| Hard time windows | `authorizedTimeWindows` — outside of it, the stop can't be planned at all. See [Hard vs soft constraints](/concepts/hard-vs-soft-constraints#hard-constraints). |
| Soft time windows / lateness penalty | `preferredTimeWindows`, tracked by the `minimizeDelay` objective. See [Hard vs soft constraints](/concepts/hard-vs-soft-constraints#soft-constraints). |
| Capacitated VRP (CVRP) | `capacities` — free-form named dimensions declared on both resources and stops. See [Capacities](/reference/data-model#capacities). |
| VRP with Pickup and Delivery (VRPPD) | Pickup- and delivery-kind stops inside the same `Order`, in array order. See [Order, stop](/reference/data-model#order-stop). |
| Skill-based / heterogeneous fleet routing | `requiredSkills` (hard match) or `preferredStopTags` with `maximizePreferredStops` (soft preference). See [Modeling advanced constraints](/guides/advanced-constraints#driver-skills-and-qualifications). |
| Multi-trip VRP (vehicle reloads mid-shift) | The depot-return pattern in [Multi-trip tours](/guides/multi-trip-tours#the-core-mechanic-pair-each-delivery-with-its-own-depot-pickup) — 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](/reference/data-model#order-stop)). Between different orders the engine has no hard precedence; you can pin a sequence yourself with [fixed assignments](/guides/manual-assignment-and-supervision). Soft: the `maximizePrecedences` objective, with tagged pairs counted inside one tour (see [maximizePrecedences](/concepts/objectives#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](/concepts/objectives). |
| 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](/guides/real-time-reoptimization). |

## See also

* [Glossary](/reference/glossary) — the full list of Kardinal-specific terms.
* [Data model](/reference/data-model) — an overview of `Resource`, `Order`, and `Stop`, each linking to its schema in the API reference.
* [How the optimization engine works](/concepts/how-the-optimization-engine-works) — objectives and the optimization loop.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.