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

# Glossary

> Unified terminology used throughout the Kardinal documentation.

| Term | Definition |
| - | - |
| Agency | The sandbox or production account scope every plan belongs to, derived automatically from the API token used to make the request (`AgencyId` in API responses). See [Moving from sandbox to production](/guides/sandbox-to-production). |
| Resource | A vehicle-driver pair for the duration of a plan — id, working hours, capacities, skills, tags, and travel profile. Called `Resource` in the API. See [Data model](/reference/data-model#resource-vehicle-driver-pair). |
| Order | One or more `stops` that must all be planned onto the *same* resource, in array order. Called `Order` in the API. See [Data model](/reference/data-model#order-stop). |
| Stop | A single visit (`SingleStop`), or a group of alternative visits of which the engine picks at most one (`AlternativesStop`), nested inside an order. See [Data model](/reference/data-model#order-stop). |
| Unique stop | The billing unit: a stop counted once per plan and per 24-hour period, as long as it keeps the same `id` and doesn't move by more than about 11 metres. See [Pricing and credits](/reference/pricing-and-credits#how-credits-work). |
| Tag | A free-form string label attached to a resource or a stop (`tags`, `requiredSkills`, `preferredStopTags`, and others) — the API defines no built-in tag values, and two sides only match by exact string. See [Driver skills and qualifications](/guides/advanced-constraints#driver-skills-and-qualifications). |
| Capacity | A free-form named dimension (weight, volume, a headcount, and so on) tracked independently on both resources and stops; a key the stop consumes but the resource doesn't declare is unconstrained on that resource. See [Data model](/reference/data-model#capacities). |
| Priority | The relative importance of an order or a resource — lower is more important, and the value can be negative — used to make an acceptable-to-drop trade-off explicit under fleet pressure. See [Soft constraints](/concepts/hard-vs-soft-constraints#soft-constraints). |
| Route | The ordered sequence of stops a single resource performs within a plan's solution — called a `tour` in the API response (`tours[]`, with `resourceId`, `distanceInKm`, `workingDuration`, and `wayPoints`). "Route" is the everyday term; `tour` is the field name you'll see in payloads. |
| Route plan (or just "plan") | The full request submitted for optimization — `resources`, `orders`, and any plan-level constraints or objectives — called `Plan` in the API. Submitting a plan doesn't return a route directly; it returns a `solution` containing one route (tour) per resource. See [Data model](/reference/data-model). |
| Solution | The engine's best result found for a plan: which tour each resource runs, which stops couldn't be placed, and the resulting objective values. Called `Solution` in the API. See [How the optimization engine works](/concepts/how-the-optimization-engine-works). |
| Objective | One entry in a plan's ordered `objectives` list, pursued in strict lexicographic priority — the first objective that separates two solutions decides which one wins. See [Objectives and how they're ranked](/concepts/objectives). |
| Hard constraint | A constraint the engine never violates — a stop it can't satisfy without breaking one is left unserved rather than the constraint being bent (`authorizedTimeWindows`, `requiredSkills`, capacities, and others). See [Hard vs soft constraints](/concepts/hard-vs-soft-constraints#hard-constraints). |
| Soft constraint | A constraint with a cost rather than a wall — the engine tries to satisfy it but accepts a violation if that's what a higher-ranked objective requires (`preferredTimeWindows`, `preferredStopTags`, and others). See [Hard vs soft constraints](/concepts/hard-vs-soft-constraints#soft-constraints). |
| Delivery window | The time window during which a `delivery`-kind stop should or must be visited — `authorizedTimeWindows` (hard: outside of it, the stop can't be planned at all) or `preferredTimeWindows` (soft: reachable outside it, at the cost of `minimizeDelay`). See [Hard vs soft constraints](/concepts/hard-vs-soft-constraints) and [Data model](/reference/data-model#time-windows). |
| Disruption | An event during execution that invalidates part of an already-computed solution and calls for a new one: a delay, a cancellation, or an urgent new order, typically. A disruption is handled by re-optimizing the affected plan, not by starting a new one — see [Real-time re-optimization](/guides/real-time-reoptimization). |
| Re-optimization | Submitting an update to a plan that already has a solution, using the **same `id`** (the `version` is incremented, and the plan re-optimized, only if its content changed; a `PUT` identical to the stored plan changes nothing and isn't billed). The engine treats this as "same problem, updated data" (the update still carries the complete plan, not only the changes): it repairs the previous solution, adjusting it just enough to be valid for the new data, then keeps improving from there, rather than searching from scratch. See [How the optimization engine works](/concepts/how-the-optimization-engine-works#continuous-and-interactive-optimization). |


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