# Phase 5 — Flight operations and dispatch

Phase 5 adds the operational workflow on top of dated Phase 4 flights. It intentionally contains no GPS, ADS-B, live-map, finance, or maintenance module.

## Dispatch and checklist controls

- Each flight has one dispatch record and one configurable operational checklist.
- Eleven standard mandatory checks are initialized, and authorized dispatchers may add custom mandatory or optional checks.
- Release is rejected until every mandatory item is complete and the assigned aircraft is confirmed.
- Dispatch release moves a Draft or Scheduled flight to Confirmed and records audit, operational, and status histories.

## Flight progression

- Actual off-block, takeoff, landing, on-block, and arrival values are stored in UTC and validated chronologically.
- Off-block values require a Released dispatch.
- Operational statuses are derived from actual times. Manual schedule editing cannot bypass Departed, In Flight, Landed, Completed, Delayed, Diverted, or Cancelled workflows.
- Bulk cancellation creates a cancellation approval record rather than changing only the flight status.

## Completion and fleet location

Actual arrival completes the flight in one database transaction. The final airport is the latest diversion final-arrival airport, the diversion airport, or the scheduled destination. The assigned aircraft is changed to Available, its manual operational airport is updated, and append-only aircraft location and status histories are recorded with source `completed_flight`.

## Security

All repository access is airline-scoped and prepared. Mutations require CSRF and granular `flights.*` permissions. Attachments use the protected upload store, checksums, MIME restrictions, canonical-path checks, and authorized private downloads. All operational mutations write both the central audit log and flight operational log.
