ACC — Predictive Operations Platform

The platform combines the operational plan with three specialised prediction models. Every relevant event updates the estimate. When a flight is projected late, a decision case brings together the context and options for people to approve.

The operational problem

Individual numbers don’t communicate the full uncertainty.

Operations teams work with scheduled times, flight-plan estimates and manual updates — useful on their own, but incomplete together.

Published schedules do not reflect today’s slot, wind or a late inbound aircraft.
Actual airborne time can drift from the flight plan in repeatable ways.
Taxi and turnaround times vary by station, stand and inbound delay.
Delays propagate through an aircraft’s later flights.
Earlier visibility gives controllers more time to assess recovery options.

One estimate chain per flight

PETD, PTOT and PETA — and the sources behind each one.

PETD — predicted off-block time. PTOT — predicted take-off time. PETA — predicted on-block time at destination. Every stage follows the same principle: a real event always overrides a prediction.

PETD — how it’s determined

Actual off-block time.
Target start-up approval time (TSAT), then target off-block time (TOBT), where published.
Aircraft rotation: the inbound aircraft’s predicted on-block time plus predicted turnaround, applied only when materially later than the current estimate and rounded to the operational planning grid.
Latest estimated departure, then scheduled departure.

A predicted departure must never be earlier than scheduled departure. If the inbound aircraft recovers time, the next flight can recover too, down to its own schedule.

PTOT — how it’s determined

At the stand: PETD plus predicted taxi-out, or calculated take-off time (CTOT) if later.
After pushback: actual off-block plus predicted taxi-out. CTOT no longer constrains the calculation.
Airborne: actual take-off time.

PETA — how it’s determined

Before landing: PTOT plus planned airborne time, the airborne model’s correction and predicted taxi-in.
After landing: actual landing plus predicted taxi-in.
At the destination gate: actual on-block time.

The airborne-time baseline comes from the operational flight plan. Without one, the route’s recent median airborne time is used, then scheduled block time minus planned taxi times. The airborne correction is applied only to a flight-plan baseline — applying it to a historical route median would correct twice.

Always current

Every relevant change places a flight in a recompute queue.

Changes to schedules, estimates, TSAT, TOBT, CTOT and actual movement events keep the chain current. Full model queries run when a flight is first seen, reaches a relevant phase, receives the inbound aircraft’s on-block event, changes aircraft, or retries an unavailable model. Every other update recalculates the chain quickly from stored model answers.

What else the platform keeps current

Automatic propagation to the same aircraft’s next flights.
Aircraft-swap handling for flights gaining and losing inbound links.
Recording aircraft changes in flight history.
Filtering impossible or incorrectly matched event timestamps.
Logging changes, sources and reasons.
Freezing snapshots at pushback and take-off to measure accuracy honestly at different horizons.

Three specialised models

Each model has its own scope and its own guardrails.

Airborne time

Predicts the deviation from the flight-plan airborne time — learns both faster and slower outcomes.

Technical detail

Uses flight-plan inputs, aircraft, route, time, season, and historical and recent operational behaviour.
Compares gradient-boosted trees and a transformer network for tabular data on live flights.
Caps corrections using historical evidence; without relevant history, applies no correction.
Training uses only information available at the prediction horizon.

Taxi-out and taxi-in

Learns deviations from planned taxi times, with a cautious, well-guarded fallback chain.

Technical detail

Excludes missing or impossible timestamps from training.
Prevents insufficient clean training data from replacing a working model.
Rejects implausible predictions.
Falls back to flight-plan taxi times, then typical station taxi times — the source used is recorded for each flight.

Turnaround

Predicts actual ground time between a specific arrival and the same aircraft’s next departure.

Technical detail

Uses strict arrival–departure pairing: the model answer is used only when its pairing matches the engine’s expected departure.
Considers scheduled ground time, aircraft family, arrival type and inbound delay — measured, before landing, with the estimate available at that moment, not the eventual actual arrival.
Applies the "no squeeze" rule: when at least the scheduled ground time is available, turnaround must not introduce a delay. Long and overnight stops are left on schedule.
Falls back to minimum ground time for the type, or no rotation push.

Uncertainty made visible

An empirically calibrated interval, not a guarantee.

Illustrative example

PETA 14:32

95% prediction interval: 14:21–14:50

Intervals are calibrated from the platform’s actual prediction errors over the previous four weeks.
Errors are grouped by phase and prediction horizon.
Each interval reflects the band containing 95% of historical errors in its group.
Calibration is updated daily.
Intervals can widen during disrupted periods and tighten as operations stabilise.
Groups with insufficient history show no interval. Obvious data errors are excluded.
Actual events replace uncertainty for completed milestones.

Calibration groups

Phase	Horizon groups
At the stand	More than 6h, 3–6h, 1–3h, under 1h to departure
Taxiing out	One group
Airborne	More than 2h, 1–2h, under 1h to arrival
Landed	One group

From prediction to decision

A case opens only when it matters — and only people approve it.

A case opens when predicted departure or arrival exceeds an airline-configured lateness threshold and the flight has not yet closed its doors.
Cases update only when estimates move materially.
Each case carries the schedule, current predictions, 95% intervals, previous estimate and sources.
The decision layer considers the station and time window, connecting passengers, later aircraft legs, crew and curfews.
An optimiser can propose holding or releasing a departure, changing the plan or recovering time in the air.
Options show their knock-on effects across the network.

Nothing is executed without human approval.

Recovery and passenger impact

Options are evaluated — not assumed.

Recovering time in the air In evaluation

Compares a short list of speed settings above the planned setting, within the aircraft family’s historical operating evidence. Shows potential minutes recovered, extra fuel and a calibrated range. Excludes options without evidence or with negligible gains. Flying faster never shows less recovery.

Passenger connections Early stage

Estimates connection outcomes under the current plan and each option, translating flight delay into passenger impact. Today this is an empirical risk table, not a machine-learning model. Predicted missed connections are compared separately against actual passenger outcomes, both as operated and against the original plan.

Re-accommodation offers Pilot

Used when a missed connection is expected and there is no same-day seat on the airline’s own network. Searches direct flights only; selects the lowest total group price, breaking ties by earliest arrival then earliest departure. Flags hotel and meal needs for an overnight wait. Prices are indicative — the system searches, it never books or pays.

Safe by design

Validated before it’s trusted — not continuously retrained in place.

Production and experimental models run side by side on the same flights.
Each experiment tests one hypothesis at a time.
Daily retraining does not automatically promote a model — promotion requires a product-owner decision based on accuracy by horizon, bias and absence of segment regressions.
Implausible predictions are rejected; insufficient or broken training data cannot replace a working model.
An unavailable model leaves the last valid answer in place and is retried on a subsequent update.
Actual events always override predictions.
Prediction history records inputs, sources and reasons for changes.
Operational action remains subject to human approval.

Component maturity

Not every component is in the same stage.

These statuses describe the platform today — not capabilities newly implemented by this website.

Component	Status	Note
Departure → take-off → arrival chain	In production	Event-driven, including rotation and aircraft-swap handling.
Airborne-time model	In production	Experiment track runs in parallel.
Taxi-out / taxi-in model	In production	Retraining guard and plan fallback.
Turnaround model	In production	"No squeeze" rule and pairing check.
95% departure and arrival prediction intervals	In production	On-screen display is being rolled out.
Decision cases	In production	People decide; nothing executes automatically.
Re-accommodation offers	Pilot	Search only, used inside decision cases.
Recovering time in the air	In evaluation	Awaiting promotion decision.
Passenger connection risk	Early stage	Currently an empirical risk table.
Baggage connection risk	Planned	Interface defined.

Getting started and integration

The estimate chain can start from the operational plan on day one.

Models contribute as sufficient airline-specific history becomes available.

Day one

Schedule with aircraft registrations.
Movement messages: off-block, take-off, landing and on-block.
Estimated times and delay updates.

Model phase

Operational flight plans, including airborne time, route, fuel, weights, planned speed and planned taxi.
Minimum ground times by aircraft type and station.
Historical operational data.

Decision phase

Passenger bookings with onward connections.
Historical fuel and speed settings.

Where available: airport milestones — TSAT, TOBT and CTOT. Data arrives as event messages. Estimates are made available for the airline’s operational systems to consume; the decision layer runs separately and reads those estimates.

Talk to us about predictive operations.

See how a continuously updated estimate chain fits into your operation.

Discuss your operational use case

Predictive Operations Platform

One estimate chain per flight.

A revised arrival moves with the aircraft.

Uncertainty narrows as the flight progresses.

Individual numbers don’t communicate the full uncertainty.

PETD, PTOT and PETA — and the sources behind each one.

Every relevant change places a flight in a recompute queue.

Each model has its own scope and its own guardrails.

Airborne time

Taxi-out and taxi-in

Turnaround

An empirically calibrated interval, not a guarantee.

A case opens only when it matters — and only people approve it.

Options are evaluated — not assumed.

Recovering time in the air In evaluation

Passenger connections Early stage

Re-accommodation offers Pilot

Validated before it’s trusted — not continuously retrained in place.

Not every component is in the same stage.

The estimate chain can start from the operational plan on day one.

Day one

Model phase

Decision phase

Talk to us about predictive operations.

Predictive Operations Platform

One estimate chain per flight.

A revised arrival moves with the aircraft.

Uncertainty narrows as the flight progresses.

How the platform works, in one paragraph

Individual numbers don’t communicate the full uncertainty.

PETD, PTOT and PETA — and the sources behind each one.

Every relevant change places a flight in a recompute queue.

Each model has its own scope and its own guardrails.

Airborne time

Taxi-out and taxi-in

Turnaround

An empirically calibrated interval, not a guarantee.

A case opens only when it matters — and only people approve it.

Options are evaluated — not assumed.

Recovering time in the air In evaluation

Passenger connections Early stage

Re-accommodation offers Pilot

Validated before it’s trusted — not continuously retrained in place.

Not every component is in the same stage.

The estimate chain can start from the operational plan on day one.

Day one

Model phase

Decision phase

How the models themselves work.

Talk to us about predictive operations.