> ## 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.

# Coming from another provider

> Generic vehicle-routing vocabulary mapped to Kardinal's own terms.

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 the Kardinal 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 (`solution.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).                                                                                     |
| Vehicle Routing Problem 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                                   | `maximizePrecedences`, an objective built from tagged "this before that" stop pairs. See [How the optimization engine works](/concepts/how-the-optimization-engine-works#what-the-engine-optimizes).                    |
| Cost / objective function                                | An ordered `objectives` list, optimized in strict lexicographic priority — not a single weighted score. See [How the optimization engine works](/concepts/how-the-optimization-engine-works#what-the-engine-optimizes). |
| Dynamic / live re-optimization                           | Submitting the same plan `id` again (`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) — field-by-field reference for `Resource`, `Order`, and `Stop`.
* [How the optimization engine works](/concepts/how-the-optimization-engine-works) — objectives and the optimization loop.