IROPS-Recovery-Advisor · Augmentierungsschicht

Wenn ein Sturm einen Hub lahmlegt, liefert StormCrew in Sekunden einen legalen Crew-Recovery-Plan.

Spielen Sie einen Sturm ein, beobachten Sie, wie der Wirkungsradius durch das Netz kaskadiert, und erhalten Sie in etwa einer Zehntelsekunde einen nach Part 117 und CBA legalen Recovery-Plan, während der manuelle Kraftakt belegte 4 bis 12 Stunden braucht. Illegale Züge werden im Code maskiert, sodass sie nicht existieren können, und wenn der Tag schlimm genug ist, eskaliert der Advisor zu einem Menschen, statt Massenstornierungen automatisch zu genehmigen.

~0.11 s

Recovery-Zeit, dieses vorgegebene Szenario

vs. belegte 4 bis 12 h manuell (research.md)

0 illegal

Part 117 + CBA durch Konstruktion

Unittest-Invariante, 3 von 3 Tests bestanden

52 von 53

Flüge neu besetzt (98%)

Vorgegebenes Szenario, Live-App-Ausgabe

Eine lauffähige Demo, kein Deployment. Das Netz, die Crews und die Störung sind synthetisch und vorgegeben, und jede Zahl auf dieser Seite stammt von der laufenden Engine.

In einem Kollaps ist der Feind ein 4- bis 12-stündiger manueller Kraftakt

Der Solver war nie das Problem. Geschwindigkeit, Legalität und Sichtbarkeit waren es.

Wenn Irregular Operations zuschlagen und ein Sturm einen Hub lahmlegt, muss das Operations Control Center die Kaskade nachgelagerter Flüge neu besetzen, die gerade ihre Crew verloren haben. Heute ist das oft ein manueller Kraftakt, der belegte 4 bis 12 Stunden dauert (research.md), unter zwei harten Constraints, die keinen Fehler zulassen: FAA Part 117 Dienst- und Ruhegrenzen sowie trägerindividuelle gewerkschaftliche CBAs.

Liegt man falsch, strandet man Passagiere und storniert Flüge. Seit die DOT-Auto-Refund-Regel im Oktober 2024 in Kraft trat, wird jede kaskadierende Verspätung von 3 Stunden plus auch automatisch zum finanziellen Schaden. Das Ausmaß ist nicht hypothetisch: IROPS kosten die Branche etwa $60B pro Jahr (IATA), und der Southwest-Kollaps vom Dezember 2022 lag bei rund $1.2B mit etwa 16,900 Stornierungen und rund 2 Millionen gestrandeten Passagieren.

Die unbequeme Wahrheit ist, dass nichts davon durch eine smartere Zielfunktion behoben wird. Die Recovery der Airline ist zu langsam, um im relevanten Zeitfenster zu zählen, zu riskant, weil ein einziger Part-117- oder CBA-Verstoß ein Compliance-Ereignis ist, und zu intransparent, weil der Wirkungsradius erst sichtbar wird, wenn Flüge bereits storniert werden. Das sind operative Probleme rund um einen Solver, keine Solver-Probleme.

StormCrew-Crew-Dienstplan, nachdem ein Sturm den DEN-Hub lahmgelegt hat, mit dem Wirkungsradius von 53 nachgelagerten Flügen, die ihre Crew verloren haben, in Amber über die Netz-Timeline hervorgehoben und der Status-Pille, die IROPS anzeigt. — Spielen Sie den Sturm ein, und der Wirkungsradius erscheint sofort: 53 nachgelagerte Flüge, die ihre Crew verloren haben, die Kaskade, die Legacy-Tools zu spät sehen.

So funktioniert es: die illegalen Züge maskieren, dann einen echten Solver wählen lassen

Deterministischer Code trifft jede Entscheidung, die zählt. Das optionale LLM liefert nur die Erzählung und sitzt vollständig außerhalb des Entscheidungskerns.

Wirkungsradius aus Graph-Erreichbarkeit

Das Lahmlegen des verkehrsreichsten Hubs früh am Tag startet die Kaskade. Der Wirkungsradius sind die lahmgelegten Flüge plus die um einen Hop nachgelagerten Flüge, die ihre Crew verlieren, berechnet durch Graph-Erreichbarkeit über die Rotation. Im vorgegebenen Szenario sind das 53 Flüge in einem Netz von 112 Flügen, 10 Stationen und 96 Crews im Dienst. Diese Menge muss neu besetzt werden, sichtbar gemacht, bevor sie zuschlägt, nicht danach.

Generierung legaler Dienste durch Action-Masking

Part 117 (maximale Dienstperiode 780 Minuten, maximale Flugzeit 480 Minuten, minimale Sit 30 Minuten) und ein Beispiel-CBA (maximal 4 Segmente) werden zur Generierungszeit durchgesetzt. Nur legale Recovery-Dienste, einschließlich Deadhead-Repositionierungen, werden jemals zu Kandidatenspalten. Eine illegale Zuweisung kann nicht erzeugt werden, also kann sie nicht gewählt werden. Das ist die ganze Idee hinter der Legalitätsgarantie: sie durch Konstruktion durchsetzen, nicht hinterher bestrafen.

Ein echter CBC-Solver wählt die kostenminimale legale Mengenpartition

Die Engine ist ein echter MIP-Solver (CBC via PuLP), kein Wrapper. Sie wählt die kostenminimale legale Mengenpartition über die Kandidaten-Dienste: jeden offenen Flug genau einmal abdecken, jede Crew höchstens einmal nutzen, wall-clock-begrenzt. Im vorgegebenen Szenario löst sie ein Problem mit 1,815 binären Variablen und 115 Constraints zu OPTIMAL. Wir legen die Engine offen und behaupten nicht, sie zu schlagen.

Shadow-Compare, dann ein Eskalationstor

Der Plan wird gegen die Nichtstun-Baseline auf einem gemeinsamen Kostenmodell bewertet: Recovery-Zeit versus dem manuellen Anker, vermiedene Stornierungen und vermiedene DOT-Auto-Refund-Exposition. Würde die Recovery mehr als die 15-Prozent-Auto-Approve-Schwelle stornieren, wechselt der Status auf ESCALATE und eine menschliche Freigabe ist erforderlich. Findet der Solver im Zeitbudget keine zulässige legale Recovery, eskaliert er ebenfalls, statt zu tun, als gäbe es eine.

Jede Empfehlung wird in einer signierten recovery_plan.json versiegelt: die Störung, der gewählte Plan mit jeder Crew und jedem Flug, die Part-117- und CBA-Klausel, die je Aktion gegen ihre Obergrenze geprüft wurde, die Recovery-Wall-Clock und die Einsparungen versus der manuellen Baseline. Es ist der Nachweis des Operations Control Center, warum diese Recovery empfohlen wurde. Ein optionaler Plan-Copilot (Standard Claude, anbieterseitig austauschbar, oder eine schlüssellose lokale Brücke) erklärt den Plan in einfachem Englisch und enthält sich ohne Schlüssel. Die deterministische Maske, der Solver und das Eskalationstor entscheiden. Der Copilot liefert nur die Erzählung.

StormCrew-Solve-Stufe, die zeigt, wie die CBC-Engine eine kostenminimale Mengenpartition über 1,815 binäre Variablen und 115 Constraints wählt, OPTIMAL zurückgibt mit 35 gewählten Spalten und einer Tabelle der gewählten Recovery-Dienste nach Crew, Flügen und Legs. — Die CBC-Solve-Stufe: 1,815 binäre Variablen, 115 Constraints, OPTIMAL. Der Solver wird als Engine offengelegt, nicht als geschlagen behauptet.

Die von StormCrew exportierte signierte recovery_plan.json, die Advisor und Engine CBC, Hub, Wirkungsradius 53, Status RECOVERED, den Hinweis zur Legalitätsgarantie, die regulatorischen Grenzen von Part 117 und CBA, Recovery-Sekunden 0.12 und Szenario-Einsparungen zeigt. — Die signierte recovery_plan.json ist das Audit-Artefakt: die geprüften regulatorischen Grenzen, die Recovery-Zeit und die Einsparungen, alles in einem exportierbaren Datensatz.

Zwei Läufe desselben vorgegebenen Sturms: recover, dann eskalieren

Jede Zahl unten ist die echte Ausgabe der laufenden Engine auf einem synthetischen vorgegebenen Netz.

Der normale Sturm recovered. Der Advisor enumeriert 1,762 legale Recovery-Dienste (52 davon Deadhead-Repositionierungen) plus 53 Cancel-Fallbacks, sodass CBC eine 1,815-Variablen-, 115-Constraint-kostenminimale Mengenpartition zu OPTIMAL löst und Status RECOVERED in etwa 0.11 Sekunden zurückgibt. Es besetzt 52 von 53 Flügen (98 Prozent) mit 34 Crews (25 Line plus 9 Reserve) neu und 1 Stornierung. Das Legalitätstor liest 52 von 52 Diensten legal, 0 CBA-Verstöße und 0 illegal, nach dem Solve verifiziert. Im Shadow-Compare gegen das Stornieren aller 53 vermeidet dieses Szenario 52 Stornierungen und etwa $2.37M DOT-Refund-Exposition, beides als illustrativ für dieses Szenario gekennzeichnet.

StormCrew-RECOVERED-Ergebnis-Modal: legale Recovery veröffentlicht in 0.12 Sekunden gegen eine manuelle Baseline von 4 bis 12 Stunden, ein Legalitätstor mit 52 von 52 Diensten legal und 0 Verstößen, 52 vermiedene Stornierungen, $2367k vermiedener DOT-Refund, beides als illustrativ gekennzeichnet, 52 Flüge neu besetzt und 98 Prozent des Radius recovered. — Das RECOVERED-Ergebnis: 52 von 52 Diensten legal, 0 Verstöße, und ein Auto-Approve-Tor, das innerhalb der Schwelle bleibt. Die Dollar- und Stornierungszahlen sind als illustrativ für dieses Szenario gekennzeichnet.

Das schwere Ereignis eskaliert. Schalten Sie auf severe um, und nur etwa 30 Prozent der Crews bleiben. CBC gibt trotzdem in etwa 0.05 Sekunden einen legalen Plan zurück, und er ist weiterhin 0 illegal, mit Recovery von 33 von 53 Flügen (62 Prozent des Radius). Aber er würde 20 von 53 Flügen (38 Prozent) stornieren, über der 15-Prozent-Auto-Approve-Schwelle, also wechselt der Status auf ESCALATE und menschliche Freigabe ist erforderlich. Der Plan wird trotzdem gezeigt und für den Controller markiert. Er wird nur nicht automatisch genehmigt. Das ist der Teil, den die meisten autonomen Pitches überspringen: zu wissen, wann der richtige Zug ist, einen schlechten Tag nicht durchzuwinken.

StormCrew-ESCALATE-TO-CONTROLLER-Ergebnis für den schweren Lauf: die Recovery storniert 20 von 53 Flügen bei 38 Prozent, über der 15-Prozent-Auto-Approve-Schwelle, daher ist menschliche Freigabe erforderlich. Das Legalitätstor liest weiterhin 33 von 33 Diensten legal, 0 Verstöße, 0 illegal, mit 33 Flügen neu besetzt und 62 Prozent des Radius recovered. — Der schwere Lauf: weiterhin legal, weiterhin sichtbar gemacht, aber auf ESCALATE für menschliche Freigabe umgeschaltet, statt 38 Prozent Stornierungen automatisch zu genehmigen.

Was haltbar ist versus was szenariospezifisch ist

Die Recovery-Zeiten, die 98 und 62 Prozent recovered, die 52 vermiedenen Stornierungen, die rund $2.37M vermiedenen Refunds und die 1,762 legalen Dienste sind alles Zahlen dieses einen vorgegebenen Szenarios. Die haltbaren Claims sind die zwei, die wir überall verteidigen können: Recovery in Sekunden gegen den belegten manuellen Benchmark von 4 bis 12 Stunden, und 0 illegal durch Konstruktion, als Invariante unittestet über die blast-radius-, legal-column- und legal-partition-Tests (3 von 3 bestanden). Die Szenario-Einsparungen vergleichen gegen eine Worst-Case-Nichtstun-Baseline, das günstigste Framing, daher kennzeichnen wir sie als illustrativ statt als Headline.

Wo StormCrew hingehört, und was diese Demo nicht tut

Der Käufer besitzt bereits einen guten Solver. Der Wert ist die operative Schicht darumherum.

Ansatz	Wie es einen Hub-Sturm handhabt	Zu Legalität und dem schlechten Tag
Manueller OCC-Kraftakt	Belegte 4 bis 12 Stunden, um die Kaskade per Hand neu zu besetzen	Legalität geprüft von müden Menschen unter Zeitdruck; der Wirkungsradius ist nicht sichtbar, bis Flüge storniert werden
Rip-and-Replace-Optimizer-Pitch	Verspricht eine smartere Zielfunktion und ein neues System of Record	Legalität als Strafterm behandelt; Lock-in-Risiko, und keine ehrliche Eskalation, wenn Recovery unmöglich ist
StormCrew (Augmentierungsschicht)	Wirkungsradius beim Einspielen; ein legaler Plan in Sekunden von einer offengelegten CBC-Engine	Illegale Züge im Code maskiert (0 illegal, unittestet); eskaliert zur menschlichen Freigabe über der Schwelle; signiertes Audit-Artefakt

Die ehrliche Haltung hier ist keine Zaghaftigkeit. Wenn der Käufer bereits einen Solver besitzt, dem er vertraut, und Lock-in oder eine unerklärte Empfehlung am schlimmsten Tag des Jahres nicht tolerieren kann, ist Augmentierung statt Ersatz der einzig glaubwürdige Einstieg. Eine Legalitätsgarantie gehört in deterministischen Code, durch Konstruktion durchgesetzt, sodass keine Wahl von Solver oder Modell sie brechen kann.

Was diese Demo NICHT tut

Sie behauptet nicht, den Solver zu schlagen oder besser zu optimieren. Sie nutzt CBC als Engine und legt das offen.
Das Netz, die Crews, die Störung und die Passagierzahlen sind synthetisch und vorgegeben. Es gibt keine echten Airline-Daten, keine echten Crew-Akten und keinen digitalen Zwilling eines echten Carriers.
Live-Feeds wie ADS-B, Crew-Positionen und Wetter sind eine wiederabspielbare Datei. Die Jeppesen- und IBS-Integration ist ein Mock-Adapter. In dieser Version läuft keine echte Integration.
Die Dollar- und Flugzahlen des Szenarios sind illustrativ für einen vorgegebenen Lauf gegen eine Worst-Case-Nichtstun-Baseline, keine garantierten Einsparungen für irgendeine Airline.
Eine trainierte GRL-Policy, ein voller digitaler Zwilling, Multi-Agent-Koordination, autonome Ausführung, umsatzgewichtete Kosten und ein DO-178C-Pfad sind alle zurückgestellt, nicht gebaut.
Das ist eine Demo, die den Mechanismus beweist. Es ist keine produktiv gesetzte Pipeline.

Fragen, die Käufer stellen

Ersetzt das unseren Jeppesen- oder IBS-Crew-Scheduling-Stack?

Nein. StormCrew ist eine Augmentierungsschicht, die im Shadow- und Advisory-Modus auf dem solverbasierten Planungsstack läuft, den Sie bereits besitzen. Sie fügt Wirkungsradius-Sichtbarkeit, eine Legalitätsgarantie, Recovery im Sekundenmaßstab und ein Eskalationstor hinzu und gibt dann einen signierten Plan zurück, den ein Controller akzeptieren kann. Es gibt kein Rip-and-Replace und kein Lock-in, weil der haltbare Wert die operative Schicht um einen Solver ist, nicht ein neues System of Record.

Sie sagen, es recovered in Sekunden. Behaupten Sie, unseren Solver zu schlagen?

Nein, und das meinen wir ernst. StormCrew nutzt einen echten MIP-Solver (CBC via PuLP) als Engine und legt das offen. Wir haben eine Smarter-Optimizer-Story gegen einen reifen Solver benchmarkt, und der Solver hat gewonnen, also haben wir den Claim geändert, nicht die Zahlen. Die haltbaren Claims sind Geschwindigkeit versus dem manuellen Kraftakt und 0 illegal durch Konstruktion, nicht Optimizer-Überlegenheit.

Wie garantieren Sie tatsächlich keinen Part-117- oder CBA-Verstoß, und nicht nur meistens?

Die Legalitätsconstraints werden zur Dienst-Generierungszeit durch Action-Masking durchgesetzt, sodass ein illegaler Recovery-Dienst niemals als Kandidat erzeugt wird. Part-117-Dienst-, Flugzeit- und Sit-Grenzen und die Beispiel-CBA-Segmentobergrenze werden angewendet, bevor der Solver jemals eine Spalte sieht, was bedeutet, dass eine illegale Zuweisung nicht existieren kann, um gewählt zu werden. Das ist eine beweisbare Invariante, unittestet als 0 illegal, kein Score, den das Modell hochzuhalten versucht.

Sind die $2.37M vermiedener Refunds eine echte Einsparung, die wir in einen Business Case schreiben können?

Behandeln Sie es als illustrativ für ein vorgegebenes Szenario, nicht als garantiertes Ergebnis. Es wird auf einem synthetischen Netz berechnet, indem der Plan des Advisors gegen eine Worst-Case-Nichtstun-Baseline verglichen wird, die den gesamten Wirkungsradius stranden lässt, mit einem $300-pro-Passagier-DOT-Refund-Modell. Das ist das günstigste Framing von vornherein und auf dem Bildschirm als illustrativ gekennzeichnet. Die unabhängig verankerten Claims sind Geschwindigkeit versus dem belegten manuellen Benchmark von 4 bis 12 Stunden und 0 illegal durch Konstruktion.

Was passiert an einem wirklich schlechten Tag, wenn Sie nicht alles recovered bekommen?

Es eskaliert, statt stillschweigend automatisch zu genehmigen. Im schweren Lauf mit erschöpften Reserven ist der Plan weiterhin legal und recovered weiterhin 33 von 53 Flügen, aber weil er 38 Prozent stornieren würde, über der 15-Prozent-Auto-Approve-Schwelle, wechselt der Status auf ESCALATE und menschliche Freigabe ist erforderlich. Der Plan wird gezeigt und markiert statt durchgewinkt, und das ist der Punkt: zu wissen, wann der richtige Zug ist, nicht automatisch zu genehmigen.

Läuft das auf echten Airline-Daten oder Live-Feeds?

Nein. Das Netz, die Crews, die Störung und die Passagierzahlen sind synthetisch und vorgegeben, ohne echte Airline-Daten und ohne echte Crew-Akten. Live-Feeds wie ADS-B, Crew-Positionen und Wetter sind eine wiederabspielbare Datei, und die Jeppesen- und IBS-Integration ist ein Mock-Adapter. Die Legalitäts-Engine und der CBC-Optimizer sind echter Code, und der manuelle Benchmark von 4 bis 12 Stunden ist ein externer belegter Anker, sodass die Demo ein getreuer Beweis des Mechanismus ist, kein Deployment.

Technische Forschung

Die Forschung hinter dieser Demo — die Architektur, das Verifikationsdesign und der Enterprise-Bauplan.

Vollständige Lösung

Die Airline-Crew-Scheduling-KI-Lösung erkunden →

Legen Sie eine Legalitätsgarantie um den Solver, dem Sie bereits vertrauen

Für VPs und Direktoren der Operations Control, Crew-Planning-Leads sowie Airline-CIOs und Ops-Tech-Teams.

Wenn Ihr Team damit ringt, das IROPS-Recovery-Fenster zu verkürzen, ohne einen Part-117- oder CBA-Verstoß zu riskieren, würden wir wirklich gerne hören, wie Sie darüber denken. Das Problem ist branchenweit, und die Antworten werden es auch sein.

IROPS-Recovery-Bewertung

✓ Review von Wirkungsradius- und Kaskadensichtbarkeit auf Ihren Rotationen
✓ Part-117- und CBA-Legalitätskodierung auf Ihren Regeln
✓ Modellierung von Recovery-Zeit und Eskalationsschwelle
✓ Eine ehrliche Einschätzung, wo Augmentierung hilft und wo nicht

Individueller Aufbau

✓ Legalitätsmaske, die illegale Dienste unmöglich zu erzeugen macht
✓ Ein echter MIP-Solver, verdrahtet mit Ihren Recovery-Constraints
✓ Eskalationstor und menschliche Freigabe auf Ihren Schwellen
✓ Signiertes Audit-Artefakt, verdrahtet in Ihren Ops-Stack, zuerst im Shadow-Modus

Über WhatsApp verbinden Unserem Team eine E-Mail schreiben