MACHINE LEARNING FOR AIRLINE OPERATIONS

Operational foresight, built on machine learning.

How specialised models connect into one operational picture — and how each one is validated before it is trusted.

Scroll to follow the operation ↓

MACHINE LEARNING FOR AIRLINE OPERATIONS

From operational signals to a prediction.

Flight plans, operational milestones and historical patterns provide different pieces of the same picture. Machine learning helps turn the information available now into an estimate of what happens next.

XGBOOST

Learning through successive corrections.

XGBoost combines decision trees into a single prediction. During training, each new tree helps reduce the errors left by the current ensemble. In production, a model already trained simply calculates the correction for this flight -- it does not retrain on each flight it sees. The XGBoost / average-historical-deviation variant is the one currently serving the production AET/EET correction.

FT-TRANSFORMER

Learning relationships between features.

FT-Transformer adapts the Transformer architecture to tabular data. Numerical and categorical features are represented as tokens, which interact through attention layers to produce a prediction. Attention between features is not a sequence in time, is not text generation, and does not by itself demonstrate causality. Today, this is used as a comparison model and as the reference signal behind the system's own change-detection and uncertainty interval -- not as the figure shown as a flight's PETA.

VALIDATION

Different models. The same operational test.

A more complex model is not automatically a better operational model. Candidates are compared against relevant baselines, using data that reflects what was known at prediction time. A lower average error can still coexist with a systematic tendency to predict early or late -- both matter.

ONE FLIGHT, CONNECTED PREDICTIONS

A revised estimate changes more than one timestamp.

PETD (off-block), PTOT (take-off) and PETA (on-block) are one connected chain for a flight, each one falling back to the next-best known time when a model answer is not yet available. A revised PETA can change the turnaround window for the next departure and the connection margin for passengers and bags. A candidate Cost-Index scenario is a separate, explicit "what if" -- not an event the chain assumes will happen.

CONTROLLED VALIDATION

Built through controlled validation, not continuous retraining.

Every candidate trains and validates on data up to a point in time, then runs in parallel with the reference it is meant to replace, on the same flights. A person reviews the comparison and decides whether to promote it. None of this happens automatically today.

Operational foresight, built on models that are explained, tested against a real baseline, and promoted only by a controlled, manual decision.

Specialised models, each with its own scope.

No single model covers every prediction. Each component below addresses one part of the operational picture, with its own target, data and validation history.

AET/EET

Learns a correction on top of the flight plan’s own estimate for the airborne phase, feeding PETA/PETD. XGBoost and FT-Transformer run side by side; the XGBoost variant is the one currently serving production.

Taxi-Out / Taxi-In

Same architecture, predicting ground movement time before take-off and after landing. Falls back to a station-level estimate or the flight plan when no model answer is available.

Turnaround

Predicts the time between an aircraft’s arrival and its next departure, paired to the immediate next rotation only. A safety floor keeps the system from ever recommending less time than the gate allows.

CIAcceleration

Estimates, for a flight already running late, how much flight time a higher Cost Index could recover and its fuel cost — as a list of candidates for a separate decision system to evaluate. Currently in evaluation, not yet in production.

Passenger- and baggage-connection intelligence is an early-stage component in this family — it does not yet use the XGBoost/FT-Transformer models described above.

See how a revised estimate moves the turnaround window.

Illustrative scenario — not live operational data. Flight XY204, synthetic numbers.

Arrival running late by 0 min

Response under evaluation No intervention Hold the next departure Candidate Cost-Index scenario

Turnaround window: 45 min (scheduled 45 min) —comfortable.

This demonstration does not run any production prediction service and does not transmit flight data. It shows how the dependencies in the previous chapter move together — not a calculated recommendation, and not an optimal decision.

General algorithms, explained from primary sources.

The algorithms themselves — XGBoost and FT-Transformer — are documented publicly. ACC’s own implementation, data and validation decisions are a separate matter, confirmed directly against our own systems, not inferred from these sources.