> ## Documentation Index
> Fetch the complete documentation index at: https://voyant.travel/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Operations
> The operations module owns operated execution truth: the availability service layer, allocation resources, resource pools, ground logistics, and places.
The operations module is where a booking stops being a commercial promise and becomes something an operator actually runs. It owns the execution side of fulfillment and ground operations: the concrete inventory units a departure has, the finite assets you assign to deliver a service, the vehicles and drivers that move travelers, and the physical places where everything happens.
It ships as `@voyant-travel/operations`, a headless module with Drizzle schema, services, and Hono routes. New code imports the owner subpaths rather than the package root:
* `@voyant-travel/operations/availability` for slots, allocation resources, pickups, and rooming. The `availability_*` tables themselves are owned by `@voyant-travel/inventory`; operations provides the service layer over them.
* `@voyant-travel/operations/resources` for resources and resource pools.
* `@voyant-travel/operations/ground` for dispatches, vehicles, and drivers.
* `@voyant-travel/operations/places` for shared physical places.
## Key concepts
These terms come straight from the [glossary](/docs/concepts/glossary). Operations is the module that holds the execution truth behind them.
* **Dispatch.** An operational order in ground to move passengers from A to B at a time, assigned to a Driver and a Vehicle.
* **Vehicle.** A transport asset (car, van, bus, coach) with capacity, class, and accessibility flags.
* **Driver.** A crew member assigned to Vehicles and Dispatches.
* **Resource.** A finite assignable asset (guide, equipment, room, driver, vehicle) with a type and availability.
* **Resource Pool.** A named collection of interchangeable Resources, such as "French-speaking guides, Cairo".
* **Resource Holds.** Operations-owned execution holds against accommodation capacity (Room Resource Hold) or a function space (Space Resource Hold). These carry the execution truth behind a MICE Program's room and space blocks.
* **Rooming List.** Traveler-to-room grouping or assignment data for a Booking.
* **Place.** A shared physical place (meeting point, pickup or dropoff place, airport, station, port, attraction, venue, accommodation location) used across OTA, tour-operator, DMC, and MICE workflows.
Capacity is always a number, never a status. A Slot has a capacity and a status; do not conflate them. Operations enforces capacity at two gates: the slot-level pax check and the per-resource check (see [fulfillment and ground ops](#fulfillment-and-ground-ops)).
## What it owns
Operations is split into four owner areas, each with its own schema, service, and routes.
### Availability and allocation resources
Availability owns the concrete dated inventory units a product can sell against, and the resources that break a slot's gross capacity into typed, individually bookable units.
* **Availability Rules** generate concrete **Slots** from an RFC 5545 recurrence. A scheduled slot is what the catalog and profitability surfaces call a "departure", exposed as the `departureLinkable` (`idPrefix: "avsl"`).
* **Closeouts** block a date or range (holiday, maintenance, sold-out override).
* **Allocation resources** are the per-slot inventory primitive for products where an operator buys a fixed block per departure (a hotel allotment, a coach seat map, a guide roster). A slot's pax bucket is the gross capacity; resources break it into typed units such as `room_dbl` or `vehicle_seat`.
* **Pickup Points** and **Pickup Groups** model where travelers are collected, dropped off, or meet.
* **Rooming and allocation exports** turn traveler-to-resource assignments into passenger and rooming CSVs.
Operators describe each option's resource mix once at the catalog level via `productOptionResourceTemplates`. When `generateAvailabilitySlots()` publishes a new slot, `materializeSlotResourcesFromTemplateDefaults()` seeds resources from those template defaults. The helper is idempotent, so re-running generation never blows away custom inventory. A `default_count` of `null` disables auto-materialisation, and vehicle-seat layouts stay out of the default path because they need a pax-aware vehicle-parent and seat-children hierarchy.
### Resources and resource pools
The resources area owns finite assignable assets that are not slot inventory: guides, equipment, and other typed resources, grouped into interchangeable **Resource Pools**. It tracks resource requirements, slot assignments, allocations, and closeouts so you can answer "which guide is free on the 28th" without overbooking a person.
### Ground
Ground owns the day-of logistics layer: **Dispatches**, **Vehicles**, **Drivers**, ground operators, transfer preferences, dispatch legs, passengers, checkpoints, and execution events. A dispatch is the operational order; vehicles and drivers are the assets it consumes; execution events record what actually happened on the ground.
### Places
Places owns shared physical locations used by every workflow. In the v1 vocabulary these are **Places**; the underlying tables and routes keep the compatibility name `facilities`. The module exports both names from the same definitions (`places` is aliased to `facilities`, `placesService` to `facilitiesService`), so you can use the canonical term in new code without a migration.
## Working with it
Standard modules are not registered by hand. `@voyant-travel/operations` is part of the standard product graph, so its routes, services, subscribers, and jobs are resolved into the application at build time. See [Configuration](/docs/platform/fundamentals/configuration).
Generate concrete slots from an availability rule, seeding allocation resources from the option's templates:
```ts theme={null}
import { generateAvailabilitySlots } from "@voyant-travel/operations/availability"
const result = await generateAvailabilitySlots(db, {
ruleId: "avrl_…",
from: "2026-05-01",
to: "2026-09-30",
})
// Newly created slots whose option has resource templates with a non-null
// default_count are auto-materialised with allocation resources.
```
Read the resource manifest for a slot before assigning travelers, then validate an allocation against per-resource capacity:
```ts theme={null}
import {
getSlotResourceAvailability,
validateSlotAllocationCapacity,
} from "@voyant-travel/operations/availability"
const manifest = await getSlotResourceAvailability(db, { slotId: "avsl_…" })
// manifest.kinds -> [{ kind: "room_dbl", capacity: 40, assigned: 6, available: 34 }]
const check = validateSlotAllocationCapacity(manifest, {
allocations: { room_dbl: "alrs_…" },
})
// A request that fits the slot's remaining pax but oversells a specific
// resource fails with a resource_capacity_exhausted violation citing the
// offending kind, resourceId, capacity, and existingAssigned.
```
Place a resource hold for a MICE program's accommodation demand, then confirm it once the booking firms up:
```ts theme={null}
import { createResourceHold, confirmResourceHold } from "@voyant-travel/operations"
const hold = await createResourceHold(db, {
kind: "room",
programId: "prog_…",
quantity: 20,
})
await confirmResourceHold(db, { holdId: hold.id })
```
Create a ground dispatch with a vehicle and driver for a transfer:
```ts theme={null}
import { groundService } from "@voyant-travel/operations/ground"
await groundService.createDispatch(db, {
bookingId: "book_…",
vehicleId: "gveh_…",
driverId: "gdrv_…",
pickupPlaceId: "fac_…",
scheduledAt: "2026-05-28T07:30:00.000Z",
})
```
### Fulfillment and ground ops
Operations is the execution end of the [commitment chain](/docs/concepts/glossary). A confirmed booking holds allocations against slots, pickups, or resources, and operations enforces both gates that must pass for a booking to confirm: the slot-level pax check (`adjustSlotCapacity`) and the per-resource capacity check used both on the read side (the slot resource manifest) and the write side (`createTravelerWithTravelDetails`). Because both sides use the same distinct-traveler count, the storefront's "available" number and the booking guard never disagree.
## Links to other modules
Operations stays decoupled and connects to the rest of the platform through links and shared references.
* **Bookings** hold the [Allocations](/docs/platform/modules) against operations slots, pickups, and resources. Operations enforces the capacity, bookings owns the commitment.
* **Catalog** owns Products and Product Options; operations reads `productOptionResourceTemplates` to know what resource mix a published slot should have.
* **Finance** references a departure (an availability slot, `idPrefix: "avsl"`) through the `departureLinkable` when allocating supplier cost for per-departure profitability. See [Finance](/docs/platform/modules/finance).
* **MICE programs** carry program-level room and space blocks; the execution truth lives in operations as Room and Space Resource Holds.
## React package
`@voyant-travel/operations-react` provides hooks, clients, query keys, and admin UI, split along the same owner areas as the headless module:
* `@voyant-travel/operations-react/availability` (plus `/availability/hooks`, `/availability/allocation`, `/availability/admin`) for slots, the allocation editor, and rooming.
* `@voyant-travel/operations-react/resources` for resources and pools.
* `@voyant-travel/operations-react/ground` for dispatches, vehicles, and drivers.
* `@voyant-travel/operations-react/places` for the places directory.
```tsx theme={null}
import { AvailabilityUiMessagesProvider } from "@voyant-travel/operations-react/availability/provider"
```
## Next steps
Allocate supplier cost to departures and report per-departure profitability.
The full catalog of domain modules and how they link.
How module-owned schemas and cross-module links are authored.
The shared vocabulary behind dispatches, resources, and places.