Every vendor selling AI into airline operations wants to tell you their optimizer is smarter. We built that product first. We benchmarked it against a mature open-source solver, CBC, and the solver won. So we changed the claim, not the numbers.
That reversal is the whole point. In an irregular-operations (IROPS) meltdown, the airline's problem was never that the solver was too weak. When a storm grounds a hub, crew recovery is too slow, too risky, and too opaque, and none of those three failures is fixed by a better objective function.
The stakes are not abstract. Southwest's December 2022 meltdown was widely reported at roughly $1.2 billion in costs, about 16,900 cancellations, and around two million stranded passengers, most of it downstream of a crew cascade that outran the recovery. Since the DOT auto-refund rule took effect in October 2024, every cascading delay past three hours is an automatic financial hit, not just an operational one. The recovery clock, not the solver, is what is expensive.
What actually collapses that clock is not a cleverer search over the same problem. It is an operational layer around a solver the airline already owns: make the cascade visible, make illegal crew assignments impossible to generate rather than merely penalized, turn the manual scramble into seconds, and know when the day is bad enough that a human, not an automation, should sign off. That is the demo we shipped as StormCrew, and you can run the whole thing at https://veriprajna.com/demos/airline-crew-scheduling-ai.
We bet on that layer instead of the objective function for one reason: durability. A better base model, or a faster solver next year, does not remove the need for a legality guarantee, an audit trail, and a decision gate. Those live outside the model, and they do not age out when the model improves.
A legality guarantee belongs in deterministic code, not in a model's judgment. Enforce it by construction, and no choice of solver or LLM can ever break it.
Legal by construction, not legal on average
An airline crew duty is either legal or it is a compliance event. FAA Part 117 caps the duty period at 780 minutes and flight time at 480 minutes, and requires at least 30 minutes of sit time between segments. The sample union CBA we encoded caps a duty at four segments. The naive way to respect those limits is to let the optimizer propose duties and then score the illegal ones with a penalty. We did the opposite. The constraints are enforced at the moment candidate duties are generated, so an illegal duty is never created, which means the solver cannot select one. It is action masking, and it turns "legal on average" into legal by construction.
The engine card: Part 117 and the CBA are masked at duty generation (max duty 780 min, max flight 480 min, min sit 30 min, max 4 segments per duty), so illegal duties are never created. The unit test reports 0 illegal of 1,762 generated duties.
Run the default seeded scenario and the difference is visible. A storm grounds the busiest hub, and the engine enumerates 1,762 legal recovery duties, including 52 deadhead repositions, then hands CBC a set-partition to cover every open flight exactly once, each crew used at most once. CBC solves it to optimal in about 0.1 seconds and re-crews 52 of the 53 exposed flights. The legality gate reports 52 of 52 duties legal, 0 violations, 0 illegal.
0 illegal by construction is not a score a better model could improve on. It is an invariant the code cannot break, and it is unit-tested: three of three checks pass.
Those three checks cover that the blast radius is non-empty, that only legal columns are generated, and that the recovered plan is a legal partition. The point is not that the number is good. The point is that no choice of solver, and no future model, can make it bad.
The published recovery: solved in 0.12s against a manual baseline of 4 to 12 hours, 52 of 52 duties legal, 0 illegal enforced in code by masking, not by the model. The $2.37M DOT-refund figure shown is labeled illustrative of this one scenario, measured against a do-nothing baseline.
The cascade you see, and the clock you beat
The other two failures get the same treatment, more briefly. The blast radius, the grounded flights plus the one-hop downstream flights that lose their crew, is computed by graph reachability over the rotation and drawn on the roster before anything cancels, so the controller sees the 53-flight cascade legacy tooling notices too late.
Inject a storm at the hub and the blast radius lights up: 53 flights at risk (amber) across the rotation, the downstream cascade surfaced before flights start cancelling.
The speed claim is the honest one, because it is anchored to something outside our own code. The recovery finishes in well under a second against a sourced manual benchmark of 4 to 12 hours (research.md). We do not claim our solver is faster than CBC. CBC is our solver. We claim the scramble collapses from hours to seconds, which is a different and far more defensible thing.
Escalate, don't rubber-stamp a bad day
The part most "autonomous" pitches skip is knowing when not to act. Toggle the severe variant, where reserves are exhausted and only about 30 percent of crews remain. CBC still returns a fully legal plan in well under a second, 0 illegal, and it recovers 33 of the 53 flights. But that plan would cancel 20 of 53 flights, which is 38 percent, above the operations control center's 15 percent auto-approve threshold. So the status flips to ESCALATE, human sign-off required, with the reason shown. The legal plan is still surfaced for the controller. It simply is not auto-approved.
Severe variant, reserves exhausted: a legal plan (33 of 33 duties legal, 0 illegal) that would cancel 20 of 53 flights, 38 percent, above the 15 percent auto-approve threshold. Status flips to ESCALATE to controller, surfaced and flagged rather than auto-approved.
An automation that quietly rubber-stamps mass cancellation on the worst day of the year is not augmentation. It is a liability. The gate is a plain deterministic rule, and it is exactly the kind of governance that a smarter model does not make unnecessary.
The record of why
Every recommendation seals into a signed recovery_plan.json: the disruption, the chosen plan, the Part 117 and CBA clause checked per action against its ceiling, the recovery wall-clock, and the scenario's savings figures. It is the operations control center's record of why a recovery was recommended, exportable and inspectable. The only LLM anywhere in the system is an optional plan copilot that puts the plan into plain English, and it abstains entirely without an API key. It narrates. It never decides. The deterministic mask, the solver, and the escalation gate decide, and they run keyless and offline.
The signed recovery_plan.json: engine CBC, status RECOVERED, the Part 117 and CBA limits (780, 480, 4 segments, 30) recorded, recovery_seconds and the illustrative savings, the exact audit artifact an OCC controller signs off.
A note on scope
The network, crews, disruption, and passenger counts are synthetic and seeded, and every figure above is one seeded scenario's result, not an open-world guarantee. In the demo the live feeds are replayed from file and the Jeppesen or IBS integration is a mock adapter, so nothing is wired to a real carrier. What is real is the mechanism: the legality mask, the CBC engine, the shadow-compare against the do-nothing baseline, and the escalation gate, all deterministic and reproducible. The two claims that do not depend on a particular scenario are the durable ones: recovery in seconds against a sourced manual benchmark, and 0 illegal by construction.
Augmentation over replacement is the only honest posture when the buyer already owns a good solver and cannot tolerate lock-in or an unexplained recommendation on the worst day of the year. So if you run an operations control center, we would genuinely like to know one thing: when your recovery process proposes a re-crew, what actually guarantees it is Part 117 and CBA legal? Is it a rule masked out in code so an illegal duty can never be generated, or a check that runs after the fact and can be overridden under pressure? The answer tends to reveal how the whole stack behaves on a bad day. The full run and the signed plan are at https://veriprajna.com/demos/airline-crew-scheduling-ai.