Home

VA Dispatch Wiki

VA Dispatch is a multi-tenant virtual-airline operations application. It gives pilots a schedule and flight-offer portal, gives dispatchers a live operations workspace and ACARS station, and gives administrators tenant and Hoppie configuration controls.

The current deployment is branded for vSAS at /vsas, while the API and database isolate records by Virtual Airline tenant.

Simulation only: VA Dispatch supports virtual-flight operations. It is not an aviation safety, navigation, or real-world operational system. All displayed and entered times are UTC / Zulu.

Start here

I want to…	Read
Understand what pilots, dispatchers, and admins can do	Product and Role Guide
Run the project locally	Local Development
Configure a deployment	Configuration Reference
Understand the system design	Architecture
Work on schedule and dispatch behavior	Scheduling and Dispatch
Work on flight lifecycle behavior	Flights and State Machines
Configure or troubleshoot Hoppie	ACARS and Hoppie
Integrate with the REST API	API Guide
Review security or GDPR responsibilities	Security and Privacy
See what is implemented and what is not	Project Status and Limitations

System at a glance

flowchart LR
    U["Pilot / Dispatcher / Admin"] --> W["Next.js web app<br/>apps/web"]
    W -->|"same-origin /api/v1"| A["Hono API<br/>apps/api"]
    W --> C["Clerk authentication<br/>and organizations"]
    A --> C
    A --> N["Neon PostgreSQL"]
    A --> H["Hoppie's ACARS"]
    V["Vercel cron<br/>every minute"] --> A

Loading

The primary production shape is a Vercel multi-service project. The Next.js service handles tenant-branded pages, Clerk sessions, and typed client interactions. The Hono service owns authorization, tenant isolation, state transitions, persistence, Hoppie traffic, and the public OpenAPI reference. Neon provides scale-to-zero PostgreSQL storage.

Current capability snapshot

Pilot

• Sign in or create an account inside the tenant-branded Clerk shell.
• Apply for pilot/dispatcher membership and wait for tenant-admin approval.
• Save a display name, simulator devices, personal aircraft ACARS callsign, SimBrief identity, and Navigraph connection.
• Request one or more flights across one or more non-overlapping UTC availability intervals.
• Edit a pending request, review linked flight offers, and choose an explicit linked-flight outcome when cancelling eligible requests.
• Accept or decline an assigned offer, review the dispatch release and OFP, generate a prepared SimBrief plan, and complete the assigned flight lifecycle.

Dispatcher

• Review, reject, cancel, partially fulfill, and complete pilot schedule requests.
• Build idempotent schedule batches or create an ad-hoc flight.
• Edit versioned flights, publish dispatch releases, prepare SimBrief plans, re-offer declined work safely, and move flights through explicit states.
• Monitor overdue/upcoming/active operations, live pilot presence, telemetry, and OOOI timestamps.
• Send and receive free-text Hoppie telex traffic and optionally link outbound messages to a flight.

Administrator

• Use every dispatcher capability.
• Configure, test, replace, or remove the tenant's encrypted Hoppie ground-station credential.
• Manage member roles/status, safe work reassignment, Clerk directory sync, direct invitations, manual applications, safe removal, tenant membership policy, privacy operations, and tenant audit events through the web control plane.

Important boundaries

• Production ACARS always uses Hoppie and fails closed until a ground-station credential is configured and tested.
• A successful Hoppie send is a store-and-forward acceptance, not a delivery or read receipt.
• The web operations board includes simulator presence and telemetry, but it is not certified navigation or real-world flight following.
• SimBrief generation remains pilot-owned even though dispatch prepares the canonical release and attribution.
• Cancelling a schedule request requires an explicit choice to preserve linked flights or cancel eligible pre-departure flights; terminal history is preserved.
• The repository provides privacy-by-default technical controls, not a legal compliance certification. Every operator remains responsible for its own legal configuration and procedures.

See Project Status and Limitations for the complete current-state boundary.

Sources of truth

Use the following order when documentation and implementation appear to disagree:

1. Runtime code and tests on the default branch.
2. The generated-in-code OpenAPI document for HTTP contracts.
3. Repository operational documents, especially README.md, docs/privacy-compliance.md, and docs/maintainer-setup.md.
4. This Wiki, which explains the preceding sources as a coherent system.

When behavior changes, update code, tests, OpenAPI, relevant repository documents, and the mirrored Wiki source in the same pull request.