Questions,
answered.

Olus is an airline disruption recovery simulator for exploring how an operations control team could respond when a schedule breaks. You start with a synthetic airline network, introduce a disruption, inspect its downstream effects, and compare recovery plans. The interface connects aircraft rotations, crew assignments, passenger impact, and operating costs. It is an engineering simulation and evaluation environment. A plan shown here is not an authorization to dispatch a real aircraft or a claim of airline certification.

A disruption recovery problem begins when the planned schedule no longer fits the resources available. An aircraft may be unavailable, an airport may lose capacity, or a crew may run out of duty time. Delaying one flight can affect the next flight assigned to that aircraft and passengers connecting elsewhere. Recovery means choosing a combination of delays, cancellations, and resource changes while respecting the constraints represented in the model. Different objectives produce different trade-offs, which is why Olus presents alternatives.

The current canonical catalog contains 22 event types: weather closure, thunderstorm, blizzard, sandstorm, dense fog, wind shear, hurricane, volcanic ash, ground stop, airspace closure, drone incursion, ATC staffing, mechanical AOG, bird strike, deicing shortage, runway closure, fuel contamination, crew sickout, labor action, security event, airport emergency, and cyber incident. Each event has its own parameters and normalization rules. Their effects are approximations for simulation; coverage of an event does not imply that every real-world operational consequence is modeled.

CP-SAT is Google OR-Tools’ constraint programming solver built around integer decisions and Boolean reasoning. Olus uses it to search recovery choices under the constraints encoded in its model. A feasible result satisfies that model’s constraints. An optimal result additionally carries the solver’s proof that no better objective value exists within that model. Time-limited runs may find a feasible solution without proving optimality. These statuses should be inspected alongside the objective, inputs, and any fallback behavior rather than treated as interchangeable.

There is no single published solve-time guarantee for this preview. Runtime depends on network size, the disruption, model constraints, search settings, hardware, and the configured time limit. A small demonstration does not establish performance for a full airline schedule. The application records solve time for individual runs, and the stress-test workspace is the place to examine behavior under different loads. Compare like-for-like scenarios and report hardware and solver settings when using those measurements. The marketing page does not claim an unmeasured 38-second median.

The recovery interface compares four objectives: operating cost, passenger impact, next-day readiness, and carbon impact. A decision that improves one measure can worsen another. For example, preserving aircraft positioning may require a different set of flight changes than minimizing immediate operating cost. Olus exposes those alternatives so a reviewer can inspect the consequences in context. Objective values depend on the assumptions encoded in the scenario and cost model. They are simulation results, not airline quotes or independently validated financial forecasts.

The crew model encodes selected flight-time, duty-period, and rest checks inspired by FAR Part 117. It evaluates assignments against the inputs and rule tables implemented in the repository. This is a bounded software model: it does not represent every regulatory exception, operating approval, contractual agreement, or jurisdiction. A green modeled check means that check passed for those inputs. It is not a statement that a real operation is comprehensively legal. Review the crew implementation, rule coverage, and scenario assumptions before interpreting a result.

No. A heuristic fallback must not inherit the guarantees of a solver result that satisfied the full encoded constraint model. Fallback behavior can help the application present a usable response when optimization cannot produce a result, but its provenance and limitations matter. Check the result status and implementation path, then inspect crew and schedule constraints separately. Even a feasible CP-SAT result is only feasible within the implemented model and supplied data. Human review remains essential when interpreting a simulation as an operational example.

The recovery workflow uses a synthetic carrier and simulated schedule rather than a private airline operations feed. Optional public weather and aircraft-position overlays can add context to the map. A public position marker is not a live dispatcher integration and does not make the synthetic schedule an airline’s actual operating plan. Saved recovery replay uses the recorded event inputs and frozen weather snapshots. Live ADS-B overlays are outside the recovery replay scope and should not be mistaken for an input that certifies a plan.

The model needs a schedule with flight identifiers, stations and times, aircraft and rotation information, crew data, and the operational constraints represented by the scenario. Disruption parameters describe which resources or locations are affected and for how long, where that duration is known. Weather snapshots can inform the prediction stage. Input consistency matters: a solver cannot compensate for missing assignments or an incorrect time window. Begin with the supplied scenarios, inspect the resulting network, and change one assumption at a time when learning the workflow.

Replay fixes the saved events and weather snapshots and uses a single solver worker with an explicit random seed. The nondeterminism audit also covers generated identifiers, event-derived random number generators, mutable weather, iteration order, and timing fields. Normal production search retains multiple CP-SAT workers for speed, so wall-clock-limited runs can return different feasible solutions. Solve duration is excluded from replay equality because elapsed time is a measurement, not a recovery decision. Determinism therefore applies to the documented replay path, not every possible live execution.

The repository includes focused tests for the optimizer, crew rules, event catalog, event propagation, prediction, persistence, and golden replay scenarios. These exercise different layers of the system rather than relying only on screenshots of successful runs. Test counts change as the project evolves, so this page does not claim that an older count is the current suite size or that every commit is green. Reproduce the relevant suite in the documented environment and inspect its output when evaluating a particular version of the model.

Yes, with a checkout of the project and the dependencies described in its setup documentation. The frontend uses Next.js, React, and TypeScript; the backend uses FastAPI and Python, with OR-Tools for optimization. Scenario persistence uses SQLite. Start from the repository’s documented environment rather than assuming a frontend preview includes a running solver service. The website and synthetic demonstration can render independently, while recovery API requests need the backend. Use the included scenarios first to confirm the full workflow is connected.

Start with an included scenario, inspect the baseline schedule, introduce a disruption, and compare the resulting recovery alternatives. Then follow one changed flight through its aircraft rotation and crew checks. For engineering evaluation, inspect the constraint implementation, replay audit, and tests alongside the user interface. Useful future work includes broader rule coverage, measured performance across larger scenarios, and clearer explanations of binding constraints. These are areas for evaluation and development, not promised release dates or evidence of an existing airline partnership.