Read the plan.
Inspect the model.

01The recovery problem #

A closure or unavailable aircraft changes more than one departure. The same tail may be assigned to later flights; its delay can propagate through a rotation. Recovery requires comparing service, cost, aircraft position and crew constraints together.

Olus uses a synthetic airline network. Start with a scenario, inject an event, compare recovery plans and inspect changed flights before applying one. Public aircraft positions provide map context; they are not the synthetic schedule.

The canonical catalog currently contains 22 disruption types. Each has parameters and normalization rules. Event coverage is a simulation approximation, not a claim to model every operational consequence.

Source: apps/api/src/events/catalog.py · EVENT_DEFAULTS

02Recovery optimizer #

The recovery optimizer uses OR-Tools CP-SAT. Boolean decisions select cancellations and eligible spare-aircraft assignments. Delay estimates are inputs from cascade prediction, not freely optimized departure times.

Financial totals are modeled exposure, not airline quotes. Compare the detailed cancellation, delay and reposition components. Carbon and passenger totals must be interpreted alongside cancellations: reducing service can reduce those totals without producing a better plan.

Inspect the returned status. Optimal means the solver proved the objective within this model. Feasible means it found a satisfying assignment without that proof. Heuristic identifies a fallback result; infeasible is not a dispatchable plan. A time limit alone does not establish optimality.

RecoveryPlan
  status: optimal | feasible | heuristic | infeasible
  cancelled_flights / delayed_flights / aircraft_swaps
  total_cost_usd / cost_breakdown
  total_passenger_delay_minutes / crew_violations
  total_co2_kg / carbon_breakdown / eu_ets_cost_usd
  uncertainty: optional expected-cost and regret analysis

For uncertain closure durations, inspect the expected cost, cost range and regret fields when returned. Do not interpret an absent uncertainty result as zero risk.

Source: apps/api/src/optimizer/milp.py · PLAN_WEIGHTS / RecoveryOptimizer; apps/api/src/optimizer/uncertain.py

03Cascade prediction #

The prediction layer estimates direct and downline delay before recovery optimization. Its implementation supports a trained predictor and rule-based propagation. Whether a trained model is available depends on the running installation; the site makes no claim about a deployed model's accuracy.

Direct disruption, first-order propagation and later cascade effects are separate states on the map and timeline. Compare the disrupted baseline with each candidate, then inspect the changed legs. A map animation illustrates the simulated movement; it is not recorded ADS-B history.

There is no published solve-time or prediction-accuracy guarantee on this page. Use measured run results and the stress-test tool with the scenario, machine and configuration recorded.

04Crew checks #

The crew engine implements selected checks inspired by FAR Part 117 using the supplied pairing and crew inputs. Its rule tables and exceptions are bounded by the implementation. A passed modeled check is not a comprehensive legal determination.

Review flight time, report time, duty duration, rest and cumulative inputs together. The aircraft-rotation ledger is explicitly a proxy where crew assignments are missing; it must not be read as an individual crew audit.

For a result, inspect the computed value, its implemented limit, remaining margin and the inputs used. Keep violations and warnings visible when comparing financial alternatives. Do not treat a cheaper plan as legal simply because it has a cost total.

Source: apps/api/src/crew/far117.py · CrewLegalityEngine; apps/web/components/simulator/crew-legality-ledger.tsx

05Data and replay #

Nimbus Air is synthetic. Network size depends on the loaded scenario. Read current schedule and fleet counts from the workspace instead of assuming a fixed demonstration size.

Optional public weather and ADS-B overlays are external context. Feed availability, stale observations and route metadata vary by provider. An inferred destination or heading projection is not a confirmed flight plan.

Deterministic recovery replay uses saved events, frozen weather snapshots, a seeded search and 1 solver worker. Normal search may use multiple workers and a wall-clock limit. Solve duration is measured separately from recovery equality.

Source: apps/api/src/optimizer/milp.py · PLAN_WEIGHTS / RecoveryOptimizer; apps/api/src/events/catalog.py

06System architecture #

The browser is a Next.js and React frontend. FastAPI serves simulator data and operations over HTTP and WebSocket. Python prediction, optimization and crew checks produce the recovery result; SQLite persists scenarios. Deployment topology is installation-specific.

Synthetic schedule + event parameters
                  |
          Cascade prediction
                  |
       OR-Tools CP-SAT recovery
          /               \
     Crew checks       Cost / carbon ledgers
          \               /
            Recovery alternatives
                  |
       FastAPI HTTP + WebSocket
                  |
       Olus operations workspace

Keep the API running when evaluating the workflow. A rendered landing demonstration does not prove the backend is connected. An offline banner or stale-data label is part of the result, not something to ignore.