The Rotation Is the Unit of Prediction, Not the Flight

Pull-quote: “By mid-afternoon, most delay is inherited. A model that scores flights one at a time is predicting the end of a process that started somewhere else that morning.”

Delay is inherited

A flight’s delay risk is mostly set by things that never appear on its own feature vector: the inbound aircraft two legs upstream, the slack in the next turnaround, a crew connection, the hub bank it lands into. In the DOT and BTS cause-of-delay categories, aircraft arriving late is consistently among the largest reported causes, and it compounds through the afternoon. A model that scores each departure independently is predicting the tail end of a process that began somewhere else, hours earlier.

That is the case for graph models in one sentence: they represent the dependency structure that single-flight models can only proxy.

A tail’s day

one tail, one operating day (illustrative)

  DCA ──leg 1──► ORD ──leg 2──► DEN ──leg 3──► PHX

  scheduled turn:         45 min         40 min         55 min
  minimum turn:           35 min         35 min         35 min
  slack:                 +10 min        + 5 min        +20 min

  morning: leg 1 departs 28 minutes late
    ► ORD turn absorbs 10 ──► leg 2 departs 18 late
    ► DEN turn absorbs  5 ──► leg 3 departs 13 late
    ► PHX turn absorbs 13 ──► the rotation recovers by evening

Every number in that sketch is knowable before noon. The turnaround buffers are in the published schedule. The inbound delay is on the surveillance feed. Turn slack, scheduled ground time minus the minimum turn, is the transmission mechanism: it decides whether delay is absorbed or passed forward. Single-flight models compress this into proxies. Graph models use it directly.

What the proxies miss

What the graph makes explicit

Model the airspace as a network: flights and airports as nodes, dependencies as edges. Three edge types do most of the work: same-tail turnarounds, crew connections, and hub topology. Message passing along those edges lets a disruption at one node update the risk of every node downstream, which is exactly how delay propagates in the physical system. Add time and you have a temporal graph: the network’s state at each scoring cycle, so a morning ground stop’s footprint moves through the model’s afternoon the way it moves through the operation’s afternoon.

This is what cascade prediction looks like in practice: graph neural networks over aircraft rotations, crew dependencies, and hub topology, re-scored as the live picture updates, so one disruption’s downstream footprint is visible before it lands.

The graph also gives the causal layer something to hold. Counterfactual questions about recovery, what would have changed if the swap happened at the previous rotation, or if the ground stop lifted an hour earlier, are questions about paths through this network. A causal engine grounded in do-calculus can answer them against the same rotation structure the cascade models score, so the prescription and the prediction share one map.

Evaluate the network, not the flight

Per-flight accuracy metrics reward a model for the easy, mostly on-time majority and hide cascade failures inside the average. Evaluation should ask the operational question instead: given a disruption at time t, how well does the model rank the set of affected downstream flights two, four, and six hours out. And calibration still applies. A cascade probability is only useful with an honest interval around it, which is what conformal calibration provides on top of the graph.

Closing

The rotation, not the flight, is the natural unit of delay prediction. Single-flight models flatten the network into averages and pay for it every afternoon. Graph models keep the structure, turn slack, crew connections, and hub banks, and let disruption propagate in the model the way it propagates on the ramp.