> ## Documentation Index
> Fetch the complete documentation index at: https://docs.planeconnection.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Trip Statuses
> Lifecycle statuses, transition rules, and leg-level vs trip-level status distinctions for operations trips.
Every trip in PlaneConnection follows a defined lifecycle beginning in Draft status, progressing through quoting, scheduling, dispatch, and flight, and ending in completion or cancellation. Trip statuses govern dispatch availability, crew commitment, and scheduling visibility across the operations module.
## Status Summary
The platform implements 12 trip statuses. The status field is defined in the database schema and enforced by the Zod validation layer and state machine transition rules.
| Status | API Value | Dispatch Impact | Description |
| --------------------------------------- | ------------ | --------------- | --------------------------------------------------------------------------------------------- |
| Draft | `draft` | None | Trip is saved but not yet submitted for review. |
| Quoted | `quoted` | None | Trip has been quoted to a client. Awaiting client approval before scheduling. |
| Requested | `requested` | None | A trip has been requested (by operator or customer) but not yet confirmed by dispatch. |
| Confirmed | `confirmed` | Soft hold | Trip has been confirmed. Aircraft and crew commitment begins. |
| Scheduled | `scheduled` | Soft hold | Trip is on the schedule. Aircraft and crew are tentatively assigned. |
| Released | `released` | Firm hold | Trip has been released to crew. Flight release checklist is issued or pending. |
| Filed | `filed` | Firm hold | Flight plan has been filed with ATC. Trip is ready for dispatch per 14 CFR 135.77. |
| Dispatched | `dispatched` | Committed | Operational release issued with dual authorization (dispatcher + PIC). Departure is imminent. |
| Active | `active` | Committed | Trip is in progress -- at least one leg has departed. |
| Close-out | `close_out` | Committed | All legs have landed. Post-flight paperwork, fuel receipts, and logs are being finalized. |
| Completed | `completed` | Released | All legs have been flown and post-flight data recorded. Terminal state -- cannot be changed. |
| Cancelled | `cancelled` | Released | Trip will not take place. Resources are freed. Can be reopened to Draft. |
The platform also supports non-flight trip types (`estimate`, `aircraft_note`, `calendar_note`) in
addition to standard flight types (`charter`, `owner`, `maintenance`, `positioning`, `training`).
Non-flight types use the same status system but may not progress through all stages.
## Trip Lifecycle
The trip lifecycle has two entry points: operators create trips starting in Draft, while customers submit trip requests that enter a lightweight qualification workflow before a trip is confirmed.
## Request qualification workflow
Trip requests move through a separate review flow before they become operational trips:
| Request status | Meaning |
| ---------------- | ------------------------------------------------------------------------------ |
| **Requested** | A customer or internal requester submitted the request. |
| **Under Review** | Dispatch is evaluating feasibility and preparing the next step. |
| **Quoted** | A quote workflow is in progress or has been sent to the customer. |
| **Accepted** | The request has been converted into a trip or explicitly accepted by dispatch. |
| **Declined** | Dispatch declined the request. |
| **Cancelled** | The requester or dispatcher cancelled the request before acceptance. |
Once a request becomes a trip, the trip itself follows the lifecycle below.
```mermaid theme={}
stateDiagram-v2
[*] --> Draft : Operator creates trip
[*] --> Requested : Customer submits request
Draft --> Quoted : Quote sent to client
Draft --> Requested : Submitted for review
Draft --> Confirmed : Operator confirms directly
Draft --> Cancelled : Creator cancels
Quoted --> Requested : Client approves quote
Quoted --> Confirmed : Quote accepted, skip request
Quoted --> Draft : Revise quote
Quoted --> Cancelled : Quote declined
Requested --> Confirmed : Dispatch confirms
Requested --> Draft : Returned to draft for edits
Requested --> Cancelled : Request denied
Confirmed --> Scheduled : Resources tentatively assigned
Confirmed --> Cancelled : Trip cancelled
Scheduled --> Released : Trip released to crew
Scheduled --> Cancelled : Trip cancelled
Released --> Filed : Flight plan filed with ATC
Released --> Scheduled : Pulled back for rescheduling
Released --> Cancelled : Trip cancelled
Filed --> Dispatched : Dual authorization complete
Filed --> Released : Pulled back before dispatch
Filed --> Cancelled : Trip cancelled
Dispatched --> Active : First leg departs
Dispatched --> Filed : Pulled back before departure
Dispatched --> Cancelled : Trip cancelled
Active --> Close_out : All legs landed
Close_out --> Completed : Post-flight data finalized
Completed --> [*]
Cancelled --> Draft : Reopened
```
## Status Transition Rules
The transition rules are enforced by the trip state machine (`TRIP_STATUS_TRANSITIONS`). The table below shows all valid transitions.
| From | To | Permitted Roles | Conditions |
| ---------- | --------------------------------------- | -------------------------- | --------------------------------------------------------------------------- |
| Draft | Quoted, Requested, Confirmed, Cancelled | Creator, Dispatcher, Admin | Quote prepared, submitted for review, or confirmed directly |
| Quoted | Requested, Confirmed, Draft, Cancelled | Dispatcher, Admin | Client approves, accepts quote, revision needed, or quote declined |
| Requested | Confirmed, Draft, Cancelled | Dispatcher, Admin | Dispatch confirms, returns to draft, or denies request |
| Confirmed | Scheduled, Cancelled | Dispatcher, Admin | Aircraft and crew tentatively assigned, or trip cancelled |
| Scheduled | Released, Cancelled | Dispatcher, Admin | Trip released to crew, or trip cancelled |
| Released | Filed, Scheduled, Cancelled | Dispatcher, Admin, PIC | Flight plan filed, pulled back for rescheduling, or trip cancelled |
| Filed | Dispatched, Released, Cancelled | Dispatcher, Admin, PIC | Dual authorization complete, pulled back before dispatch, or trip cancelled |
| Dispatched | Active, Filed, Cancelled | Dispatcher, Admin, PIC | First leg departure, pulled back before departure, or trip cancelled |
| Active | Close-out | Dispatcher, Admin, PIC | All legs have landed; cannot cancel while in flight |
| Close-out | Completed | Dispatcher, Admin, PIC | Post-flight data entered and finalized (14 CFR 135.63) |
| Completed | (none) | -- | Terminal state -- no further transitions |
| Cancelled | Draft | Dispatcher, Admin | Reopen cancelled trip as a new draft |
Active trips cannot be cancelled. This is a safety constraint -- you cannot cancel a trip while
aircraft are in flight. If a leg must be diverted or cut short, the trip remains Active until all
legs land, then transitions to Close-out.
Completed is a locked terminal state. Unlike Cancelled (which can be reopened to Draft), a
completed trip cannot be modified. A new trip must be created instead.
## Pipeline Stages
The trip pipeline displays 11 stages (excluding Cancelled) in the dispatch pipeline view, numbered sequentially:
| Stage | Status | Label |
| ----- | ------------ | ---------- |
| 1 | `draft` | Draft |
| 2 | `quoted` | Quoted |
| 3 | `requested` | Requested |
| 4 | `confirmed` | Confirmed |
| 5 | `scheduled` | Scheduled |
| 6 | `released` | Released |
| 7 | `filed` | Filed |
| 8 | `dispatched` | Dispatched |
| 9 | `active` | Active |
| 10 | `close_out` | Close-out |
| 11 | `completed` | Completed |
## Dual-Authorization Dispatch
The transition from Filed to Dispatched requires **dual authorization** per 14 CFR 135.77. Both the dispatcher and the pilot-in-command must independently approve the operational release before the trip can be dispatched.
| Authorization | Who | What they confirm |
| ------------- | ------------------- | ------------------------------------------------------------------------- |
| Dispatcher | Dispatcher or Admin | Weather, NOTAMs, crew duty compliance, aircraft airworthiness, fuel plan |
| PIC | Pilot-in-Command | Acceptance of the flight release, route review, personal fitness for duty |
The same person cannot serve as both dispatcher and PIC for the same trip. Each authorization is timestamped and recorded on the trip for audit purposes.
A trip cannot advance to Dispatched until both authorizations are recorded. If either party has
concerns, the trip remains in Filed status until the issue is resolved or the trip is pulled back
to Released.
## Leg-Level vs Trip-Level Status
A trip consists of one or more legs. Legs carry their own status independently from the trip.
| Leg Status | API Value | Description |
| ---------- | ----------- | --------------------------------------------------- |
| Scheduled | `scheduled` | Leg is planned but has not departed. |
| Active | `active` | Leg is in progress -- departed but not yet arrived. |
| Completed | `completed` | Leg has arrived and post-flight data is recorded. |
| Cancelled | `cancelled` | Leg will not be flown. |
### Derivation Rules
| Condition | Trip Status |
| ----------------------------------------------------------------- | ------------------------------------------------------- |
| All legs are `scheduled` | Confirmed (or Scheduled, depending on validation state) |
| At least one leg is `active` | Active |
| All legs are `completed` | Close-out (pending post-flight finalization) |
| All legs are `cancelled` | Cancelled |
| Mix of `completed` and `cancelled` (none `scheduled` or `active`) | Close-out |
## Trip Record Fields
| Field | Type | Required | Description |
| ---------------- | --------- | :----------------: | ------------------------------------------------------------------------------------------------ |
| `trip_number` | String | Auto | Unique trip identifier (e.g., `TRP-2026-0142`). |
| `status` | Enum | Auto | Current lifecycle status (defaults to `draft`). |
| `trip_type` | Enum | No | Charter, owner, maintenance, positioning, training, estimate, aircraft\_note, or calendar\_note. |
| `aircraft_id` | Reference | Yes (at Scheduled) | Assigned aircraft tail number. |
| `origin` | String | Yes | Departure airport ICAO code. |
| `destination` | String | Yes | Arrival airport ICAO code. |
| `departure_at` | Timestamp | No | Planned departure date and time. |
| `arrival_at` | Timestamp | No | Planned arrival date and time. |
| `requested_by` | String | No | Person or entity that requested the trip. |
| `department_id` | String | No | Optional department association. |
| `quote_id` | String | No | Linked quote (for charter trips). |
| `estimated_cost` | Real | No | Estimated trip cost. |
| `notes` | Text | No | Internal notes (BlockNote JSON format). |
| `version` | Integer | Auto | Optimistic locking version counter. |
| `created_at` | Timestamp | Auto | Record creation timestamp (UTC). |
| `updated_at` | Timestamp | Auto | Last modification timestamp (UTC). |
## Scheduling Conflict Detection
When a trip transitions to Scheduled or Confirmed, the system checks for conflicts:
| Conflict Type | Detection Rule | Resolution |
| ----------------------- | ------------------------------------------------------------- | ------------------------------------------ |
| Aircraft double-booking | Same aircraft assigned to overlapping time windows | Warning at Scheduled; blocked at Confirmed |
| Crew double-booking | Same crew member assigned to overlapping trips | Warning at Scheduled; blocked at Confirmed |
| Duty time exceedance | Crew assignment would exceed 14 CFR Part 135 Subpart F limits | Blocked at Confirmed |
| Aircraft maintenance | Aircraft is in maintenance status during trip window | Blocked at Scheduled |
## Related
Trip creation and confirmation.
Tutorial walkthrough of the trip lifecycle.
How aircraft availability affects trip scheduling.
Real-time dispatch states for aircraft and FRAT assessments.