Insights ── Aviation ── 2026-05-04

Faster or slower — a real-time recommendation in the cockpit

In flight operations the captain constantly faces speed trade-offs: recover from delay, hit slots, save fuel, meet curfews. A real-time recommendation system quantifies the options — costs against costs — and delivers a concrete recommendation to the cockpit, with audit trail.

Autor Matthias ── Lesezeit 3 Min
Faster or slower — a real-time recommendation in the cockpit
Fig.01

Faster or slower? An answer before the flight rolls. In flight operations there are constant trade-offs between time and fuel: catch up on delay because connections are at risk. Fly intentionally slower because the slot at destination is tight. De-risk a curfew. Hold a sustainability window. So far these decisions were distributed, qualitative, often gut feeling. Today a quantified recommendation comes into the cockpit as a telex message — in real time, with audit trail.

This is a productive Speed-Up / Slow-Down Recommender in a 24/7 flight operation. Several data streams, one recommendation core, context-specific recommendations. Here is how it works.

What the system delivers

Six data streams in the same second. Live position and fuel state of the aircraft. Operational flight plan with planned remaining consumption. Daily fuel prices. ATC remaining time to destination. Slot and curfew constraints at the destination. Context data for the trigger — for misconnect risk, e.g., the list of transferring passengers plus per-passenger costs; for slot compliance, the slot tolerances at the destination.

One calculation per trigger context. Misconnect risk is one trigger — the first one that went productive, because the pain was most direct there. Other triggers in the same system:

  • Schedule Recovery — delay against fuel for standard booking risks
  • Slot Compliance — intentionally slower to hit the arrival window at the destination
  • Curfew Compliance — faster to reach the noise window before closure
  • Crew Duty Time — adjust speed to stay within duty limits
  • Sustainability — save fuel when time reserves allow
  • Connecting Passengers — connection protection with per-passenger cost weighting

Every trigger uses the same data foundation and the same recommendation core. What differs are the cost models and thresholds — maintained as runtime configuration, without code deploy per new trigger.

The recommendation as a telex. Costs against costs, in plain text for the captain:

“You can burn up to X kg of additional fuel to make up Y minutes — damage avoidance Z €.”

Or: “Save up to X kg if you arrive W minutes later — slot stays within the tolerance window.”

The decision is made by the pilot. The system delivers the quantified basis — not for just one trade-off, but for every trade-off that appears in flight operations.

Why the data foundation makes this possible

What lets the system answer in seconds is not the system itself — but the platform underneath. All data streams are already integrated. A fully historized vault layer makes the values retrievable without querying foreign source systems in the hot decision loop. The cost logic sits as a declarative, low-code-configurable rule set — maintainable by business analysts, without an engineer ticket.

What a standalone point solution would take weeks to deliver becomes a configuration question on top of the platform foundation. A new trigger is set up on existing data streams, with the same audit trail and the same deployment pipelines as every other service.

What changes operationally

Gut feeling becomes a documented trade-off. Every speed recommendation is traceable — who received which recommendation, on which data basis, at what time, and which decision was made. Operationally valuable. Audit-proof toward internal audits and authorities.

The decision stays with the pilot — where it belongs. What changes is the quality of the basis. From “feels right” to “X kg, Y minutes, Z €”.

New triggers become a configuration task. Sustainability as a trigger, weather avoidance as a trigger, commercial connection protection as a trigger — these are configurations on an existing platform, not separate software projects.

Operational speed trade-offs exist in every 24/7 flight operation. The data streams for it are there — rarely integrated in a platform, even more rarely with a configurable recommendation core on top. If this lever is dormant at your operation, a conversation in the Tactical Assessment is worth it.