A schedule can look perfect and still be impossible — an aircraft in two places at once, a turnaround that can't be made. Deconfliction is finding those conflicts at the desk instead of at the gate.
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 common conflict types:
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.
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.
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.
A schedule is a list of flights; an operation is a set of aircraft each flying a connected sequence. Turning one into the other — building rotations and checking they're physically possible — is where the schedule meets reality.
A carrier's network philosophy is written into its schedule — in the banks at its airports, the degree of its stations, and the shape of its route graph. Here's how to read it.
An origin–destination matrix turns a wall of flight legs into a picture of where a network flows. Here's how to read one built from a schedule — and, just as importantly, what it can and can't tell you.
