AI system replicated flight dispatchers’ decision affecting 296 passengers

An airport is temporarily closed, an aircraft is stranded, and it still has several flights scheduled that evening. Canceling the departure with the fewest passengers seems sensible—until it turns out there is nowhere to rebook them. A busier flight can sometimes be easier to remove from the schedule: nearby departures have available seats, and canceling it leaves the aircraft where it needs to be next.

This was the problem Sergey Ershov’s team examined with an unnamed Russian airline. According to the authors, they built eight AI tools and, after a series of fixes, replicated a decision made by an employee in the commercial department: cancel a pair of flights carrying 296 passengers. The passengers could be accommodated on other departures over the next two days while preserving the aircraft’s subsequent schedule.

The model reads messages, Python counts seats

The most useful detail in this case is the division of labor. The language model interprets the text or screenshot of a disruption notice and produces explanations. Conventional Python scripts calculate flight loads, available seats, rankings, and other figures. An employee checks the result before proceeding to the next stage.

The system gathers airport restrictions, identifies affected flights, and checks rebooking options and aircraft movements. It then considers a possible aircraft substitution and assembles an overall scenario. Employees upload data as files from the scheduling system, the Leonardo reservation system, and BI. In the project described, the tool had no direct connection to operational systems.

Imagine two flights whose passengers are to be rebooked onto the same nearby departure. If each is checked separately, the same available seats can easily be promised twice. The system therefore allocates seats from a shared pool. This check may seem routine, but it determines whether an attractive cancellation proposal can actually be carried out.

A real disruption exposed rules missing from the brief

The first evaluation used a July disruption for which the employees’ decision was already known. The system put the same flights at the top of its cancellation list. Errors began to emerge with a more complex August scenario.

For example, the tool deemed a flight impossible because its arrival time fell within a restriction period. However, the airport was operating on a “subject to approval” basis at the time: this required a separate decision, rather than automatic cancellation. Another clarification concerned outbound and return flights operated by the same aircraft. A commercial decision often needs to cover the pair together, taking account of the passengers and consequences of both flights.

Errors also surfaced in time processing. When filtering notices, a message lifting a restriction could fall outside the selected period. In one calculation, the system returned 1093 minutes instead of 1346. The authors linked the events imposing and lifting restrictions and added checks for intervals spanning midnight.

It also became clear that the tool needed to stop and consult a specialist when schedule data conflicted. Continuing calculations with contradictory data produced an unreliable result.

What 164 runs demonstrate

The authors report 164 runs of a single August scenario. The final workflow comprised 13 steps, including creating an Excel file, checking the export, and producing a calculation log. After revisions, the system selected the same pair of flights as the employee, with the same explanation: canceling them preserved subsequent departures and avoided delaying those flights by roughly two hours.

This is a useful reproducibility check, but its scope is limited. Repeated runs of one scenario are no substitute for evaluation on independent disruptions. The article provides no measurements of time savings, financial impact, or the proportion of incorrect recommendations. Matching a specialist’s decision does not, by itself, prove that the chosen option was optimal.

For developers, the case offers a concrete guide: first isolate calculations, constraints, and stopping points, then bring in the model to interpret incoming messages. Product managers should establish in advance how to compare recommendations with employees’ work on new cases. The core work in this kind of deployment is to extract rules from the team’s experience and make every decision verifiable.