Cancellations Optimizer

The problem

Airlines lose aircraft to weather, mechanical issues, delivery delays and fleet-wide groundings. When only a few are unavailable the schedule absorbs it. When many are, the airline has to cancel flights — and choosing which ones is a genuinely hard trade-off between passengers stranded, revenue lost, connecting traffic broken, and markets left without service that day.

After the Boeing MAX grounding, an executive debrief identified the opportunity: make that call quickly and defensibly, at a speed that matches how fast the situation moves. Scenarios were built by hand and each one took a day, so cutting that down meant planners could weigh real alternatives while the aircraft were still on the ground.

The model

The unit of decision is a rotation — a round trip out of the hub and back. Freeing an aircraft means cancelling a set of rotations that together account for its entire day. I formulated this as a mixed-integer program: binary variables choose which rotations to cancel, and the objective minimizes a weighted blend of impacted passengers, revenue, interline (other-airline) passengers, daily frequency, and wingtip coverage.

Those weights are not fixed. Planners set them per run, which matters because the right answer genuinely differs by situation — protecting connecting traffic and protecting revenue pull the solution in different directions, and the tool makes that trade explicit instead of burying it.

Constraints

• ▸Canceled rotations must free each aircraft for a full 24 hours a day — a partial gap is useless operationally.
• ▸Selected rotations cannot overlap in time.
• ▸Turnaround between consecutive rotations stays between 1 and 3 hours.
• ▸Each rotation can be selected at most once.

These came from the planning team rather than from the data. A model that satisfies the math but proposes an operationally impossible schedule is worse than no model.

Making it solvable

A correct formulation that never finishes is not a tool. Most of the engineering went into getting the solve time down from hours to minutes:

• Reformulation. Pre-aggregating rotations into sets that already account for 24 hours of aircraft usage collapsed the hardest constraint — find a combination totalling a full day — into a simple selection. This was the single biggest win.
• Variable scaling. Scaling every variable to a 0.1–1 range improved numerical stability and solver speed, and made each term's true weight in the objective legible.
• Solver choice. The first version used OR-Tools with the open-source SCIP solver. It handled the basic model but slowed dramatically once the full objective was added. Migrating to Gurobi's API resolved it and simplified the code.
• Parallel solves. Running multiple optimizations concurrently and stopping at the first viable solution cut wall-clock time further.

How it is used

The system is five modules, so that each piece can be validated on its own:

Data integrator

Pulls schedule, passenger and revenue data from the warehouse and reshapes it for optimization. Queries were tuned for parallel execution and staged through temporary tables so the optimizer never waits on I/O.

Optimizer

Solves the mixed-integer program: which rotations to cancel, given the weights a planner chose and the operational constraints that must hold.

Parameter GUI

Lets planners set how much each factor matters — passengers, revenue, interline traffic, daily frequency, wingtip coverage — and how many aircraft need freeing, then runs the whole pipeline.

Validator

Independently re-checks every constraint against the produced solution and reports any violations. It caught errors during development and, more importantly, lets planners trust a schedule enough to act on it.

Solutions visualizer

Draws a timeline per aircraft showing exactly which rotations are cancelled, alongside the resulting impact metrics, so the recommendation is auditable rather than a black box.

Results

<20 min

To produce a viable plan, from over 2 hours in the first iteration

20

Aircraft shortage size the model solves for

1 day → 0

Manual planning effort replaced by a parameterized run

Beyond speed, the weights turned out to matter as much as the solve. Benchmarking two runs that differed only in how much frequency was valued produced visibly different cancellation sets — fewer single-frequency markets cut in one, more revenue protected in the other. That flexibility is what made it a decision-support tool rather than a single fixed answer.

Stack

Related writing

• Mathematical Optimization Isn't Theory: It's How the World Runs

  Where a model like this one sits among the decisions optimization already runs.

• Fast-Time Simulation: Testing Decisions Before You Make Them

  The complement to optimization: how an operation behaves before you decide what to do about it.