Airline Operations Dashboard

Methodology — how these numbers were generated

Every number on this page is synthetic. Here's the calculation, and the reasoning behind each choice, in full.

Why a single fictional airline, not a benchmark across many

The sibling Flight Delay Prediction Dashboard answers an OTA's question — "which routes/airlines should I flag as delay-risky?" — across five carriers. This dashboard answers a different question an airline's own ops team asks about itself: "how is my operation actually performing, by hub and over time?" One carrier, tracked in depth, is the right shape for that question — a multi-airline benchmark would be the wrong tool for it.

The calculation, step by step

For every one of the 6,000 simulated flights, in order:

• On-time performance: starts from a base probability of 90%, reduced by that hub's congestion index (Delhi and Kolkata run busiest), then reduced further by −22pp if the hub is fog-sensitive and the month is Dec/Jan, or −14pp if monsoon-sensitive and the month is Jun–Sep.
• Cancellation: decided separately as its own probability (base 0.6%, +hub congestion, +weather exposure). A cancelled flight is always counted as not on-time, but never the reverse — cancellation is the more severe outcome.
• Load factor: drawn from a normal distribution around a base of 79%, shifted up in the Oct–Nov festive season and down in the Jan–Feb low season and at monsoon-exposed hubs during monsoon months.
• Revenue: ticket revenue = passengers × a per-hub base fare × a seasonal fare multiplier (higher in festive season, discounted in low season). Ancillary revenue (bags, seats, meals) is added per passenger on top. Both are zero for a cancelled flight.
• Complaints: drawn from a weighted distribution that shifts hard toward more complaints when the flight was delayed, and harder still when it was cancelled — the one deliberate correlation this generator exists to demonstrate, not background noise.
• Baggage mishandling: one independent per-bag draw, rate rising with hub congestion and on any day operations went irregular (delayed or cancelled).

A data-quality decision worth naming: two different passenger counts

The dataset tracks passengers_expected (a demand estimate, computed the same way regardless of outcome) separately from passengers_boarded (zero for a cancelled flight, by definition). Load factor and revenue are correctly built on boarded passengers, since those only exist for flights that actually flew. But the first version of this analysis used boarded passengers as the denominator for the complaints-rate metric too — which made cancelled flights show zero complaints per 1,000 passengers, the exact opposite of reality, purely because a cancelled flight boards nobody. Complaints are rated against expected passengers instead: the people actually affected by the flight, whether it flew or not. Same kind of judgment call as excluding cancelled flights before averaging delay minutes in the sibling dashboard — a metric's denominator has to match what the metric is actually claiming to measure.

Why these specific numbers

Not derived from any real source — chosen, then checked against public ballpark ranges for plausibility (domestic OTP typically 70–88%, load factor typically 75–85%, baggage mishandling typically 4–8 per 1,000 bags across the industry). The fleet-wide numbers here — 77.9% on-time, 78.9% load factor, 5.4 bags mishandled per 1,000 — all land inside those ranges. The relative patterns (which hub is worst, which season hurts which hub, that delays and cancellations both drive up complaints) are what the model was actually built to produce, and are the point of the exercise.

What this deliberately doesn't model

It doesn't fit real distributional parameters from any published dataset — there wasn't one available in this environment. It doesn't model knock-on delay (one late inbound aircraft delaying that same tail number's next departure) — a real ops model would need that, and it's a materially harder problem than this exercise scopes to. Every flight is generated independently; it's built to produce the aggregate patterns an ops dashboard needs, not to be an operations simulator.

Full source: projects/airline-operations-dashboard/generate_dataset.py and analyze.py in the repo — every number above is reproducible from those two files.