Deconfliction: catching overlapping flights before they bite

Here’s an uncomfortable truth about schedules: a file can pass a basic parse, look tidy in a grid, and still describe something that cannot physically happen. An aircraft assigned to two flights at once. A turnaround shorter than the time it takes to get passengers off and on. A flight listed twice. Finding these before they reach operations is deconfliction — and it’s some of the highest-leverage checking a schedule team can do.

The conflicts that hide in a clean-looking schedule

The common conflict types:

• Aircraft double-use. The same tail is assigned two flights whose times overlap — it would have to be in two places at once.
• Impossible turnarounds. Two consecutive legs on the same aircraft leave less ground time than the minimum needed to turn it — the second flight can’t depart on time, if at all.
• Duplicate flights. The same flight number operates twice on the same date, often from two overlapping series that both got published.
• Overlapping periods. Two flight-leg series cover the same flight on the same day with different details — which one is true?
• Slot and curfew breaches. A flight that doesn’t sit on a held slot, or departs inside an airport curfew, is a conflict with a constraint outside the file.

Why “looks fine” isn’t enough

None of these show up if you only read flights one at a time. They’re relational — a conflict exists between two flights, or between a flight and a constraint. A grid view shows you each row; it doesn’t tell you that row 4,812 and row 9,033 are the same aircraft at the same moment. You have to reason across the whole schedule at once.

And the cost of missing them scales with how full the operation is. In a year of record load factors and a scarce fleet, there’s no spare aircraft to paper over a double-assignment and no empty seats to absorb a misconnect. A conflict caught at the desk costs a schedule edit; the same conflict caught at the gate costs a delay, a recovery, and a bad day for everyone downstream.

Validation asks “is this flight well-formed?” Deconfliction asks “can all these flights coexist?” — and that second question is where operations actually break.

Where deconfliction sits

Deconfliction belongs at every seam of the planning cycle: when a new season is built, when a change stream has been applied, before a schedule is published, and whenever two versions are merged. It’s not a one-time gate; it’s a check you want to run cheaply and often, because the schedule keeps moving.

Doing it well

Catching these conflicts means holding the whole schedule in view and reasoning across it: overlapping legs on a tail, turnarounds against minimum ground times, duplicate flights, period collisions, slot mismatches — surfaced deterministically, at the desk. That’s precisely one of the core workflows SSIM Toolkit is built around: bring the schedule in, and see the conflicts that a row-by-row view can never show you — locally, reproducibly, before they reach the gate.

That closes the operations arc of the series. Next, the series turns to the engineering and the economics: build vs buy for a schedule parser, and why local-first, deterministic tooling is the right foundation.