IROPS Recovery Advisor · Augmentation Layer

When a storm grounds a hub, StormCrew returns a legal crew-recovery plan in seconds.

Inject a storm, watch the blast radius cascade across the network, and get a Part 117 and CBA legal recovery plan in about a tenth of a second, where the manual scramble takes a sourced 4 to 12 hours. Illegal moves are masked out in code, so they cannot exist, and when the day is bad enough the advisor escalates to a human instead of auto-approving mass cancellations.

~0.11 s

Recovery time, this seeded scenario

vs sourced 4 to 12 h manual (research.md)

0 illegal

Part 117 + CBA by construction

Unit-tested invariant, 3 of 3 tests pass

52 of 53

Flights re-crewed (98%)

Seeded scenario, live app output

A runnable demo, not a deployment. The network, crews, and disruption are synthetic and seeded, and every number on this page is produced by the running engine.

In a meltdown, the enemy is a 4 to 12 hour manual scramble

The solver was never the problem. Speed, legality, and visibility were.

When irregular operations hit and a storm grounds a hub, the operations control center has to re-crew the cascade of downstream flights that just lost their crew. Today much of that is a manual scramble that runs a sourced 4 to 12 hours (research.md), done under two hard constraints that leave no room for a mistake: FAA Part 117 duty and rest limits, and per-carrier union collective bargaining agreements.

Get it wrong and you strand passengers and cancel flights. Since the DOT auto-refund rule took effect in October 2024, every 3-hour-plus cascading delay also becomes an automatic financial hit. The scale is not hypothetical: IROPS cost the industry about $60B a year (IATA), and the Southwest meltdown of December 2022 ran roughly $1.2B with about 16,900 cancellations and around 2 million stranded passengers.

The uncomfortable truth is that none of this is fixed by a smarter objective function. The airline's recovery is too slow to matter in the window that matters, too risky because a single Part 117 or CBA violation is a compliance event, and too opaque because the blast radius is not visible until flights are already cancelling. Those are operational problems around a solver, not solver problems.

StormCrew crew duty roster after a storm grounds the DEN hub, with the blast radius of 53 downstream flights that lost their crew highlighted in amber across the network timeline and the status pill showing IROPS. — Inject the storm and the blast radius appears at once: 53 downstream flights that lost their crew, the cascade legacy tools see too late.

How it works: mask the illegal moves, then let a real solver choose

Deterministic code makes every decision that matters. The optional LLM only narrates, and it sits entirely outside the decision core.

Blast radius from graph reachability

Grounding the busiest hub early in the day starts the cascade. The blast radius is the grounded flights plus the one-hop downstream flights that lose their crew, computed by graph reachability over the rotation. In the seeded scenario that is 53 flights across a network of 112 flights, 10 stations, and 96 crews on duty. That set is what needs recovering, surfaced before it bites rather than after.

Legal-duty generation by action masking

Part 117 (maximum duty period 780 minutes, maximum flight time 480 minutes, minimum sit 30 minutes) and a sample CBA (maximum 4 segments) are enforced at generation time. Only legal recovery duties, including deadhead repositions, ever become candidate columns. An illegal assignment cannot be produced, so it cannot be chosen. This is the whole idea behind the legality guarantee: enforce it by construction, not by penalizing it after the fact.

A real CBC solver picks the min-cost legal set-partition

The engine is a real MIP solver (CBC via PuLP), not a wrapper. It selects the minimum-cost legal set-partition over the candidate duties: cover every open flight exactly once, use each crew at most once, wall-clock-bounded. In the seeded scenario it solves a problem of 1,815 binary variables and 115 constraints to OPTIMAL. We disclose the engine and do not claim to beat it.

Shadow-compare, then an escalation gate

The plan is scored against the do-nothing baseline on a shared cost model: recovery time versus the manual anchor, cancellations avoided, and DOT auto-refund exposure avoided. If the recovery would cancel more than the 15 percent auto-approve threshold, the status flips to ESCALATE and human sign-off is required. If the solver finds no feasible legal recovery in the time budget, it also escalates rather than pretending.

Every recommendation is sealed into a signed recovery_plan.json: the disruption, the chosen plan with each crew and flight, the Part 117 and CBA clause checked per action against its ceiling, the recovery wall-clock, and the savings versus the manual baseline. It is the operations control center's record of why this recovery was recommended. An optional plan copilot (default Claude, provider-swappable, or a keyless local bridge) explains the plan in plain English and abstains without a key. The deterministic mask, the solver, and the escalation gate decide. The copilot only narrates.

StormCrew solve stage showing the CBC engine selecting a min-cost set-partition over 1,815 binary variables and 115 constraints, returning OPTIMAL with 35 columns chosen and a table of chosen recovery duties by crew, flights, and legs. — The CBC solve stage: 1,815 binary variables, 115 constraints, OPTIMAL. The solver is disclosed as the engine, not claimed to be beaten.

The signed recovery_plan.json exported by StormCrew, showing the advisor and engine CBC, hub, blast radius 53, status RECOVERED, the legality guarantee note, the Part 117 and CBA regulatory limits, recovery seconds 0.12, and scenario savings. — The signed recovery_plan.json is the audit artifact: the regulatory limits checked, the recovery time, and the savings, all in one exportable record.

Two runs of the same seeded storm: recover, then escalate

Every figure below is the running engine's real output on one synthetic seeded network.

The normal storm recovers. The advisor enumerates 1,762 legal recovery duties (52 of them deadhead repositions) plus 53 cancel fallbacks, so CBC solves an 1,815-variable, 115-constraint min-cost set-partition to OPTIMAL and returns status RECOVERED in about 0.11 seconds. It re-crews 52 of 53 flights (98 percent) with 34 crews (25 line plus 9 reserve) and 1 cancellation. The legality gate reads 52 of 52 duties legal, 0 CBA violations, and 0 illegal, verified after the solve. Shadow-compared against cancelling all 53, this scenario avoids 52 cancellations and about $2.37M of DOT-refund exposure, both labeled illustrative of this scenario.

StormCrew RECOVERED result modal: legal recovery published in 0.12 seconds against a 4 to 12 hour manual baseline, a legality gate reading 52 of 52 duties legal and 0 violations, 52 cancellations avoided, $2367k DOT refund avoided both labeled illustrative, 52 flights re-crewed, and 98 percent of the radius recovered. — The RECOVERED result: 52 of 52 duties legal, 0 violations, and an auto-approve gate that stays within threshold. The dollar and cancellation figures are labeled illustrative of this scenario.

The severe event escalates. Toggle severe and only about 30 percent of crews remain. CBC still returns a legal plan in about 0.05 seconds, and it is still 0 illegal, recovering 33 of 53 flights (62 percent of the radius). But it would cancel 20 of 53 flights (38 percent), above the 15 percent auto-approve threshold, so the status flips to ESCALATE and human sign-off is required. The plan is still shown and flagged for the controller. It just is not auto-approved. This is the part most autonomous pitches skip: knowing when the right move is not to rubber-stamp a bad day.

StormCrew ESCALATE TO CONTROLLER result for the severe run: recovery cancels 20 of 53 flights at 38 percent, above the 15 percent auto-approve threshold, so human sign-off is required. The legality gate still reads 33 of 33 duties legal, 0 violations, 0 illegal, with 33 flights re-crewed and 62 percent of the radius recovered. — The severe run: still legal, still surfaced, but flipped to ESCALATE for human sign-off rather than auto-approving 38 percent cancellations.

What is durable versus what is scenario-specific

The recovery times, the 98 and 62 percent recovered, the 52 cancellations avoided, the roughly $2.37M refund avoided, and the 1,762 legal duties are all this one seeded scenario's numbers. The durable claims are the two we can defend anywhere: recovery in seconds against the sourced 4 to 12 hour manual benchmark, and 0 illegal by construction, unit-tested as an invariant across the blast-radius, legal-column, and legal-partition tests (3 of 3 pass). The scenario savings compare against a worst-case do-nothing baseline, which is the most favorable framing, so we label them illustrative rather than a headline.

Where StormCrew fits, and what this demo does not do

The buyer already owns a good solver. The value is the operational layer around it.

Approach	How it handles a hub storm	On legality and the bad day
Manual OCC scramble	A sourced 4 to 12 hours to re-crew the cascade by hand	Legality checked by tired humans under time pressure; the blast radius is not visible until flights cancel
Rip-and-replace optimizer pitch	Promises a smarter objective function and a new system of record	Legality treated as a penalty term; lock-in risk, and no honest escalation when recovery is impossible
StormCrew (augmentation layer)	Blast radius on inject; a legal plan in seconds from a disclosed CBC engine	Illegal moves masked out in code (0 illegal, unit-tested); escalates to human sign-off past the threshold; signed audit artifact

The honest posture here is not timidity. When the buyer already owns a solver they trust and cannot tolerate lock-in or an unexplained recommendation on the worst day of their year, augmentation over replacement is the only credible way in. A legality guarantee belongs in deterministic code, enforced by construction, so no choice of solver or model can break it.

What this demo does NOT do

It does not claim to beat or out-optimize the solver. It uses CBC as its engine and discloses it.
The network, crews, disruption, and passenger counts are synthetic and seeded. There is no real-airline data, no real crew records, and no digital twin of a real carrier.
Live feeds such as ADS-B, crew positions, and weather are a replayable file. The Jeppesen and IBS integration is a mock adapter. No real integration runs in this version.
The scenario dollar and flight figures are illustrative of one seeded run against a worst-case do-nothing baseline, not guaranteed savings for any airline.
A trained GRL policy, a full digital twin, multi-agent coordination, autonomous execution, revenue-weighted cost, and a DO-178C path are all deferred, not built.
This is a demo that proves the mechanism. It is not a deployed pipeline.

Questions buyers ask

Does this replace our Jeppesen or IBS crew-scheduling stack?

No. StormCrew is an augmentation layer that runs in shadow and advisory mode on top of the solver-based planning stack you already own. It adds blast-radius visibility, a legality guarantee, second-scale recovery, and an escalation gate, then hands back a signed plan for a controller to accept. There is no rip-and-replace and no lock-in, because the durable value is the operational layer around a solver, not a new system of record.

You say it recovers in seconds. Are you claiming to beat our solver?

No, and we are deliberate about this. StormCrew uses a real MIP solver (CBC via PuLP) as its engine and discloses it. We benchmarked a smarter-optimizer story against a mature solver and the solver won, so we changed the claim rather than the numbers. The durable claims are speed versus the manual scramble and 0 illegal by construction, not optimizer superiority.

How do you actually guarantee no Part 117 or CBA violation, and not just usually?

The legality constraints are enforced at duty-generation time by action masking, so an illegal recovery duty is never created as a candidate. Part 117 duty, flight-time, and sit limits and the sample CBA segment cap are applied before the solver ever sees a column, which means an illegal assignment cannot exist to be chosen. This is a provable invariant unit-tested as 0 illegal, not a score the model tries to keep high.

Is the $2.37M in avoided refunds a real saving we can put in a business case?

Treat it as illustrative of one seeded scenario, not a guaranteed outcome. It is computed on a synthetic network by comparing the advisor's plan against a worst-case do-nothing baseline that strands the entire blast radius, using a $300 per passenger DOT-refund model. That is the most favorable framing by design and is labeled illustrative on screen. The independently anchored claims are speed versus the sourced 4 to 12 hour manual benchmark and 0 illegal by construction.

What happens on a genuinely bad day when you cannot recover everything?

It escalates instead of silently auto-approving. In the severe run with reserves exhausted, the plan is still legal and still recovers 33 of 53 flights, but because it would cancel 38 percent, above the 15 percent auto-approve threshold, the status flips to ESCALATE and human sign-off is required. The plan is shown and flagged rather than rubber-stamped, which is the point: knowing when the right move is not to auto-approve.

Is this running on real airline data or live feeds?

No. The network, crews, disruption, and passenger counts are synthetic and seeded, with no real-airline data and no real crew records. Live feeds such as ADS-B, crew positions, and weather are a replayable file, and the Jeppesen and IBS integration is a mock adapter. The legality engine and the CBC optimizer are real code, and the 4 to 12 hour manual benchmark is an external sourced anchor, so the demo is a faithful proof of the mechanism rather than a deployment.

Technical Research

The research behind this demo — the architecture, the verification design, and the enterprise blueprint.

Full solution

Explore the Airline Crew Scheduling AI solution →

Put a legality guarantee around the solver you already trust

For VPs and directors of operations control, crew planning leads, and airline CIOs and ops-tech teams.

If your team is wrestling with how to collapse the IROPS recovery window without risking a Part 117 or CBA violation, we would genuinely like to hear how you are thinking about it. The problem is industry-wide and the answers will be too.

IROPS recovery assessment

✓ Blast-radius and cascade visibility review on your rotations
✓ Part 117 and CBA legality encoding on your rules
✓ Recovery-time and escalation-threshold modeling
✓ An honest read on where augmentation helps and where it does not

Custom build

✓ Legality mask that makes illegal duties impossible to generate
✓ A real MIP solver wired to your recovery constraints
✓ Escalation gate and human sign-off on your thresholds
✓ Signed audit artifact wired into your ops stack, shadow-mode first

Connect via WhatsApp Email Our Team