DEV Community: DisNoire

Comparator contract violations in aircraft stand sorting

DisNoire — Thu, 03 Sep 2026 13:34:11 +0000

Third post about the engineering inside an airport slot coordination platform. The first two — lossless schedule repacking and conflict detection with Union-Find — were about algorithms I designed. This one is about a bug I inherited, and about the most misunderstood exception in Java.

The incident

While bringing an abandoned flight-operations service back to life, production threw this at me:

java.lang.IllegalArgumentException: Comparison method violates its general contract!

Not from some exotic subsystem — from a stream's .sorted(comparator) in the endpoint that lists aircraft stand states ordered by parking-area code (under the hood, sorted buffers into an array and hands it to Arrays.sort — TimSort). A request that sorted stands by code simply aborted. Sometimes. On some data. Not in tests, not on staging, and not reproducibly on demand — which is this exception's signature move, and the reason it's so widely misread as a JDK bug.

It isn't one. It's the JDK catching you.

What the contract actually says

Every Java developer can recite the Comparator interface: negative, zero, positive. Far fewer can recite the three laws the JavaDoc actually demands:

Antisymmetry: sgn(compare(a, b)) == -sgn(compare(b, a)) — if a beats b, then b must lose to a. Always. Both directions must agree.
Transitivity: if a beats b and b beats c, a must beat c.
Consistency: if compare(a, b) == 0, then a and b must agree in how they compare against everything else.

Why TimSort notices, and why only sometimes

Since Java 7, Arrays.sort for objects is TimSort — a merge sort that hunts for already-ordered runs and merges them with a galloping optimization. That machinery relies on the total-order laws: when it gallops through a run, it trusts that what compared "less" stays "less" from every direction it checks.

Hand it a comparator that lies, and one of two things happens. If the input happens not to expose the lie, the sort completes — perhaps correctly, perhaps subtly misordered. If the input does expose it, TimSort's internal invariants collapse and it throws the contract exception rather than return garbage.

Two consequences worth noting:

The exception is data-dependent. That's why it passed every test and failed in production on Tuesdays. A broken comparator is a landmine; TimSort only reports the mine when someone steps on it. Absence of the exception proves nothing.
The exception is a gift. Pre-Java-7 merge sort would have silently produced a wrong order. There's even an escape hatch — -Djava.util.Arrays.useLegacyMergeSort=true — and reaching for it is the classic wrong fix: it doesn't repair the comparator, it just asks the JDK to stop telling you about it.

The actual bug

Parking-area codes are mostly letter-plus-number — B2, B10 — sorted "naturally", so B2 precedes B10. But the population also contains letter-only codes (A, B) and empty strings — states whose parking area is simply absent, collapsed to "". The comparator I inherited split each code into a numeric part and a letter part, parsed the numbers, compared them — and handled the no-number cases in a branch chain that ended like this:

// reached when a code has no numeric part
} else if (numPart1.isBlank()) {
    return 1;                        // fires regardless of what numPart2 is
}

When both codes lacked digits — A vs B, or anything vs "" — that branch fired in both argument orders: compare("A","B") == 1 and compare("B","A") == 1. Textbook antisymmetry violation. And the letter-comparison written to handle exactly this case sat just below the branch, unreachable — dead code guarding the live bug. My favourite detail: compare("A","A") == 1 too. Under this comparator, a letter-only stand wasn't even equal to itself.

The matrix view makes the lie visible: antisymmetry demands that the grid mirror-negate across a zero diagonal. The numeric codes (top-left) obey. The letter-only-and-empty corner is a solid block of +1 — nine cells of contradiction, three of them on the diagonal itself.

So for most requests — most stands carrying ordinary numeric codes — the sort held. Let enough letter-only or parking-less states into one response, in positions where TimSort's merge compares them from both directions, and the request died. The bug had sat quietly in an inherited codebase until the data found it.

There was a second, quieter landmine in the same method: Integer.parseInt on an unvalidated digit run — one unexpectedly long code away from NumberFormatException. Nothing in production had tripped it yet; it went into the same fix anyway.

The fix: compare digits without parsing them

The repair restructured the branches so every case returns a consistent answer from both directions:

// after — every path total and symmetric (illustrative shape, not production source)
if (bothHaveNumbers) return compareNumericallyThenByLetters(a, b);
if (aHasNumber)      return -1;   // numeric codes sort first…
if (bHasNumber)      return 1;    // …seen from either side
return lettersOf(a).compareTo(lettersOf(b));   // both letter-only: the once-dead branch, now alive

Two details in the "numerically" part: ties between equal numbers break on the letter part, so compare == 0 only ever means genuinely interchangeable — law three's cheap insurance. And the numeric comparison stopped parsing entirely: digit runs compare as strings — longer significant run wins, equal lengths compare lexicographically — which is overflow-proof at any code length. Ordering for every previously-valid code is unchanged; only the lies are gone.

Then the step that mattered as much as the fix: auditing the sibling comparators. The same endpoint also sorts by arrival and departure flight time; both of those delegate to OffsetDateTime.compareTo — a valid total order — which exonerated them for this crash. But the audit still paid: both could NPE, because a state can legitimately lack its arrival or departure flight, and every candidate time field can be null. Their fix was a null guard plus Comparator.nullsLast(...) — with a note to the product owner that whether missing times sort first or last is a product decision, not something a comparator should decide by accident. Defects cluster; code written in the same week shares the same blind spots.

Proving it, not eyeballing it

A fixed comparator that "looks right" is exactly as trustworthy as the previous one looked. The laws are properties, so the proof is property-based: a sandbox harness mirroring the production logic, generating randomised datasets of stand codes — numeric, letter-only, empty, null-adjacent — and asserting the three laws directly:

for every pair: sgn(compare(a,b)) == -sgn(compare(b,a))
for every triple: transitivity holds
for every "equal" pair: both elements order identically against every third value

First, the harness reproduced the exact production exception against the old comparator — no fix is proven until the bug is reproduced. The reproduction also measured the size of the landmine: across 4,000 randomised datasets, the original comparator threw in 1,582 of them. Two out of every five random datasets could kill the endpoint; production had been surviving on the luck of its data mix. Against the fixed comparator: zero law violations, zero sort exceptions, zero mis-ordered outputs across all 4,000, plus targeted regressions for the original failing case, leading zeros, and numeric-vs-letter precedence. The harness stayed in the suite; it now guards every future edit to those comparators.

This is the same philosophy the first two posts kept arriving at, wearing a different coat: the repacking pipeline has a set-equality guard, conflict detection asserts its example before drawing conclusions, and comparators get their laws fuzzed. Don't inspect correctness — check it, mechanically, every time.

What I'd generalise

Interfaces have laws, not just signatures. Comparator, equals/hashCode, Comparable — the compiler checks the shape and never the laws, and the laws are load-bearing. The most dangerous code in a codebase is a five-line method everyone assumed was too simple to be wrong.

Data-dependent failures demand law-based tests. Example-based tests encode the inputs you thought of; the production data will think of others. When correctness is a property, test the property.

When you find one, check the others. A broken comparator is rarely alone. The half-day spent auditing siblings bought more reliability than the fix itself.

And don't take the escape hatch. useLegacyMergeSort silences the messenger. The exception told the truth: the contract was violated. Fix the contract.

I build airport slot coordination and airline schedule systems — IATA telegram processing, schedule algorithms, conflict detection — in Java. Currently relocating to Spain. Earlier in this series: schedule repacking · conflict detection. Find me on LinkedIn.

Conflict detection in airline schedules

DisNoire — Tue, 01 Sep 2026 16:12:19 +0000

Second post about the algorithms inside an airport slot coordination platform. The first one was about repacking schedules into canonical form. This one is about the question a coordinator asks right after: which of these rows are fighting over the same slot?
Part 3. Comparator contract violations in aircraft stand sorting

The setup

An airport slot coordination system stores schedules as rows of (validity period + weekday mask) — a compact representation whose care and feeding I covered last time. A season schedule runs to hundreds of flights and, in our production system, 300,000+ rows. Rows arrive from several directions at once — coordination telegrams, draft edits, imports — and sometimes the schedule ends up with rows of the same flight whose operating dates collide: the same flight identity holding competing claims for a date. That's a conflict — and note it's strictly a same-flight affair; in this model, two different flights cannot conflict with each other.

A coordinator can't act on a schedule in that state. The system's job is to find every such situation across the whole collection and show it — fast enough to run interactively, on every check.

Why the obvious answer is wrong twice

The obvious answer is to compare every row with every other — and I don't have to speculate about how that goes, because that's what the check did when I met it. On a 14,799-row collection, all-pairs is

14,799 × 14,798 / 2  ≈  109 million comparisons

— each involving date-range expansion. Across the full 300,000-row production schedule, the same shape reaches ~45 billion. In practice the check ran for about 20 seconds. I watched that spinner, did this arithmetic, and decided the algorithm didn't deserve its runtime.

Twenty seconds is the first "wrong": quadratic cost on a collection that, as the previous article showed, is inflated by representational fragmentation to begin with. Fragmentation and pairwise comparison compound each other — every unnecessary sliver multiplies against every other row.

The second "wrong" is subtler and more interesting: pairs are the wrong output shape. If row A collides with row B, and B collides with C, that is not two findings — it's one conflict involving three rows, and the coordinator needs to see it whole to resolve it. Conflict is a transitive, relational property. A list of pairs pushes the grouping work onto the user's eyeballs.

Conflicts are groups, not pairs. What we're really computing is the connected components of a collision relation.

Idea one: never compare strangers

The definition above does half the work for us: conflicts are same-flight by construction, so rows belonging to different flights never need to be compared at all. Before any date is expanded, partition the collection by flight identity — airline and flight number.

One linear pass with a hash map, and the one huge n² shatters into thousands of tiny problems — most clusters holding a handful of rows. This is where the 45 billion goes to die: almost every pair the naive version compared was a pair that could never conflict.

One wrinkle: a schedule row in a slot system describes a turnaround — an arrival leg and a departure leg, each with its own flight identity. So a single row participates in two clusterings, once by its arrival identity and once by its departure identity. Hold that thought; it's where the output gets its precision.

Idea two: groups are connected components

Within each cluster, expand rows to their operating dates. Two rows collide when they share a date. And because we want groups, not pairs, we don't record collisions — we merge them, with a Union-Find — also known as a disjoint-set union, DSU — the textbook structure for "who's in the same group":

final class UnionFind {
    private final int[] parent;
    private final int[] rank;

    UnionFind(int n) {
        parent = new int[n];
        rank = new int[n];
        for (int i = 0; i < n; i++) parent[i] = i;
    }

    int find(int x) {
        while (parent[x] != x) x = parent[x];
        return x;
    }

    void union(int a, int b) {
        int ra = find(a), rb = find(b);
        if (ra == rb) return;
        if (rank[ra] < rank[rb])      parent[ra] = rb;   // smaller tree under bigger
        else if (rank[ra] > rank[rb]) parent[rb] = ra;
        else { parent[rb] = ra; rank[ra]++; }
    }
}

Mine used union by rank — always hang the shallower tree under the deeper root, which bounds find at O(log n). The textbook goes further: add path compression and the amortized cost drops to inverse-Ackermann, i.e. effectively constant. I didn't bother, and that's a deliberate point, not a confession: after the identity partition, each cluster holds a handful of rows, and log of a handful is nothing. The asymptotic profile of the union structure never showed up in a profiler — the clustering had already done the heavy lifting. Optimizing the Union-Find further would have been polishing the doorknob on a door we'd already removed.

The mechanics within a cluster: walk each row's dates, keep a map from date to the first row seen on that date; when a second row lands on an occupied date, union the two rows. At the end, every disjoint set with more than one member is one conflict group — the A–B–C chain falls out for free:

Row A:  01JUN–30JUN  1......      (Mondays, all June)
Row B:  15JUN–15JUL  1......      (Mondays, mid-June to mid-July)
Row C:  01JUL–31JUL  1......      (Mondays, all July)

A and C never share a date. But A–B collide in late June, B–C collide in early July — so union chains all three into one component. One conflict, three rows, exactly what the coordinator must see to fix it. A pairwise report would have shown two separate findings and left the user to discover they're one problem.

The output: not just "conflict", but which leg

Because each row was clustered twice — by arrival identity and by departure identity — the result can say which side of the turnaround is at fault. Each row gets marked arrival-conflicted, departure-conflicted, or both (a row whose arrival leg collides in one cluster and whose departure leg collides in another carries both flags), plus a total conflict count for the collection. The UI highlights the exact leg, not just the row.

That leg-level precision is the difference between an alarm and a diagnosis. "This row is in conflict" sends the coordinator hunting; "this row's departure is double-claimed on 12 dates" tells them where to cut.

What it costs now

Two passes, each effectively linear: one hash-map partition over all rows, then per-cluster date walks with cheap unions.

Before: ~20 seconds for the check across the production schedule — a spinner, a context switch, a thing you schedule around.
After: a 14,799-row collection checks in 20 ms — a keystroke.

Fast enough that conflict detection stopped being a batch job you schedule and became a property of the schedule you simply always see.

Wait — didn't the repacking article make this problem disappear?

Fair question, if you read the previous post: if schedules get canonicalized into overlap-free form, what's left to detect?

The two algorithms treat different diseases. A repacked row carries exactly one operational payload — one departure time, one aircraft, one set of business fields — so repacking can only merge rows that agree on everything except how their dates are written. It removes redundant duplication: the same claim, encoded messily. But two rows of the same flight with different payloads on colliding dates are not redundancy — they're contradiction. The canonical example from our production data: the same flight number claiming two different airports on the same date. A plane cannot land in two cities at once, and no algorithm should resolve that by silently picking a winner — deciding which claim is true is the coordinator's job. (Milder versions abound: same flight, same date, different departure times, different aircraft.) Repacking is forbidden to touch that pair, so it survives canonicalization — and surfacing it, whole and precisely blamed, is what conflict detection is for.

Tidy the redundancy automatically; hand the contradictions to a human. The boundary between those two is the most important line in the whole system. And it compounds with the repacking from article #1: canonical schedules keep n small; near-linear detection keeps the check cheap at any n. The two algorithms are one story — representation hygiene and cheap verification, feeding each other.

What I'd generalize

Name the output shape before choosing the algorithm. The naive version wasn't slow because pairwise comparison is slow — it was slow because pairs were never the answer. The moment the requirement was stated as "groups", the structure (connected components, Union-Find) was inevitable. Most O(n²) scans hiding in business systems are really badly-shaped questions.

Partition by identity before comparing by value. The two-level shape — coarse hash partition on an identity key, fine relational pass within each bucket — turns quadratic problems near-linear whenever most pairs can be excluded by a cheap key. It's the same trick as a hash join, wearing domain clothes.

Precision of blame is a feature. Clustering each row twice (per leg) cost almost nothing and turned the output from "something's wrong here" into "cut this leg on these dates". The cheapest UX win in the whole system came from the algorithm's bookkeeping, not the UI.

I build airport slot coordination and airline schedule systems — IATA telegram processing, schedule algorithms, conflict detection — in Java. Currently relocating to Spain. The previous post in this series: lossless repacking of airline schedules. Find me on LinkedIn.

Lossless repacking of airline schedules

DisNoire — Thu, 27 Aug 2026 18:55:27 +0000

How a compact schedule representation creates an equivalence-class problem, and how we repack fragmented schedules into minimal form — with a guarantee we never lose a single operating date.
Part 2. Conflict detection in airline schedules
Part 3. Comparator contract violations in aircraft stand sorting

The representation

Airlines don't publish their schedules as lists of dates. A flight that operates every Monday, Wednesday and Friday all summer is one line, not ninety:

XX123  KZN → MAD   01JUN–30SEP   1.3.5..

That last field is a weekday mask in the IATA convention — digits 1–7 for Monday through Sunday, dots for days the flight doesn't operate. 1.3.5.. reads: Mondays, Wednesdays, Fridays.

The whole industry runs on this. SSIM files, slot-coordination telegrams, airport capacity systems — everywhere a repeating flight appears, it appears as a (validity period, weekday mask) pair. It's compact, humans can read it, and a season's schedule fits on a screen.

I work on an airport slot coordination platform — the system through which airlines request arrival and departure slots and airports allocate them. Our schedule rows use exactly this representation. And it has a property that looks harmless and isn't:

The same set of operating dates has many valid representations.

These three schedules are the same flight:

A:  01JUN–30JUN  1.3.5..   B:01JUN–15JUN  1.3.5..  C:01JUN–30JUN  1......
                             16JUN–30JUN  1.3.5..    01JUN–30JUN  ..3....
                                                     01JUN–30JUN  ....5..

Expand any of them to concrete dates and you get the identical set. A is one row. B is two. C is three. Operationally they are indistinguishable — and that's the problem.

How schedules fragment

Nobody writes version C on purpose. It emerges.

A coordinator moves the Friday departure time for two weeks in July: the edit has to split the row, because the change applies to a sub-range of the period and one day of the mask. An airline cancels three specific dates: more splits. A season of ordinary edits later, a flight that is conceptually "Mon/Wed/Fri all summer" is stored as a dozen slivers — short periods, sparse masks, some of them describing a single date in period-and-mask costume.

And this is not a per-flight issue — it compounds across the whole schedule. A season schedule is hundreds of flights, and ours runs to more than 300,000 rows before repacking. The repacker works group by group — rows are keyed by flight number and leg, and each group's operating dates are an independent equivalence-class problem — but the payoff sums over the collection: at the ~40% reduction we measured on production schedules, that's over a hundred thousand rows of pure representational debris removed, with not one operating date touched.

Fragmentation isn't just untidy:

Humans read these rows. A slot coordinator scanning a fragmented schedule can't see the shape of the operation. Twelve slivers hide the pattern that one row states plainly.
Everything downstream iterates over rows. Conflict detection, telegram generation, schedule comparison — all of it scales with row count, and much of it is worse than linear. Our conflict detection was O(n²) before we replaced it — fragmentation was directly inflating the n. (A story for another day)
Comparisons produce false differences. Diffing an incoming schedule against a stored one when their periods don't share boundaries is its own hard problem — fragmentation multiplies it.

So we built a repacking operation: take a flight's rows, produce the minimal set of (period, mask) rows that generates exactly the same dates.

Why this is harder than "merge adjacent periods"

The naive instinct is interval merging — the classic coalesce-overlapping-ranges exercise. It fails here immediately, because rows interact across two dimensions that don't compose independently: the calendar axis and the weekday axis.

Two rows with identical masks and adjacent periods can merge along the period axis. Two rows with an identical period and different masks can merge along the mask axis (union the masks). But most real pairs are neither: they overlap partially in period and differ in mask, and merging them naively either invents dates that were never in the schedule or drops dates that were.

There's a subtler trap, too. A period–mask pair can encode dates that look different but generate the same set. 01JUN–30JUN ....5.. and 06JUN–27JUN ....5.. are the same Fridays — the first period's edges are slack, because June 1st isn't a Friday. Any correct algorithm has to reason about the generated date set, not about the period boundaries as written.

Which points at the only safe definition of equivalence:

Two schedule representations are equal if they expand to the same set of operating dates.

Everything else follows from taking that definition seriously.

The algorithm

Repacking runs as a pipeline: expand, deduplicate, then rebuild in three stages, cheapest structure first.

Stage 0 — expand and deduplicate

Expand every row to its concrete dates. Drop exact duplicates — rows whose entire date set is already covered by other rows contribute nothing and exist only as editing debris. What remains is the ground truth: one set of dates per flight number and leg (departure / arrival / return) — the unit whose rows describe the same operational data, and the only scope within which rows are ever combined.

From here on, the original rows are irrelevant. We rebuild from the dates.

Stage 1 — contiguous runs at a 7-day stride, per weekday

For each weekday independently, sort that weekday's dates and find maximal runs where consecutive dates are exactly 7 days apart. Each run becomes a candidate row: period = first to last date of the run, mask = that single weekday.

This stage alone converts "every Friday from June to September, except the two cancelled ones" into three tight single-weekday rows instead of a scatter of fragments. Crucially, the periods that come out of this stage are taut — they start and end on dates the flight actually operates, which eliminates the slack-boundary ambiguity by construction.

Stage 2 — the trivial merges first

The cheap cross-weekday case: candidate runs whose periods coincide exactly merge immediately into one row with the union of their masks. The Monday, Wednesday and Friday runs for the same June–September stretch collapse into a single 1.3.5.. row.

Stage 3 — greedy first-fit combination, tested for holes

What's left is the awkward remainder: runs that almost fit together. The final pass is greedy, first-fit: pick a column — one weekday's run — and walk the other runs until you find a partner that merges without holes. A proposed merge takes the union period (earliest start to latest end) and the union mask, expands the resulting row, and accepts it only if every date the merged (period, mask) implies is a real operating date — no holes in the implied grid, no phantom dates beyond the truth. First valid partner wins; repeat until no pair merges. The scan tries weekday-adjacent masks first.

The January flight in the examples below shows this pass earning its keep: the Monday run's concise period is 05JAN–09FEB and the Tuesday run's is 06JAN–03FEB — different boundaries, so no trivial merge — yet the union row 05JAN–09FEB 12..... implies exactly the real dates, and the merge stands.

The guard: every stage proves itself

Here is the part of the design I'd defend hardest.

After every stage, the pipeline expands its own output and compares the generated date set against the ground truth from Stage 0. Set equality, or the stage's result is rejected.

Set<LocalDate> truth = expand(originalRows);

List<Row> candidate = stage.apply(rows);
if (!expand(candidate).equals(truth)) {
    // this stage's optimisation is not lossless for this input —
    // reject it and continue with the previous representation
    candidate = rows;
}

And when no lossless packing exists for some residue of dates — irregular cancellations often leave one — there's a per-date fallback: those dates are emitted as single-date rows. Ugly, but correct, and correctness is not negotiable here. A schedule row in a slot coordination system is an airline's permission to land. An optimization that silently drops one Friday in August is not a performance bug; it's a plane with nowhere to go.

This guard is what let us ship aggressive optimization stages without fear. The greedy stage can be wrong about a merge — the guard catches it. A future maintainer can add a fourth stage with a subtle bug — the guard catches that too. The invariant is enforced structurally, not by hoping every stage is individually perfect.

Minimal-ish, provably lossless

Note what we did not build: an optimal minimiser. Finding the guaranteed-smallest set of (period, mask) rows is a set-cover-shaped problem, and greedy-with-verification gets ~40% row reduction on production schedules at a complexity a team can maintain. We chose absolute correctness and good-enough minimality over provable minimality — because the guard makes the first property certain, and nobody's operations depend on the second being perfect.

What it looks like in practice

Two anonymized examples — two flights out of the hundreds a single repack pass walks.

Example 1 — same row count, radically better rows. Three stored rows for one flight:

05JAN–26JAN  123...7
13JAN–02FEB  12...67
02FEB–09FEB  12...67

Thirty date-markings, but only 23 distinct dates — seven dates are covered twice, because the rows overlap in both period and mask (every Monday and Tuesday from 13JAN to 26JAN lives in two rows at once). The repack emits:

05JAN–09FEB  12.....
07JAN–21JAN  ..3....
11JAN–08FEB  .....67

Still three rows — but zero overlap, each period concise against its first and last operating date, and the operational shape (Mon/Tue core, Wednesdays for three weeks, weekends from mid-January) now readable at a glance. This is the case that taught us row count is the wrong success metric on its own: the real product is canonical, overlap-free form. Double-covered dates are quiet poison for anything downstream that counts, diffs or allocates by date.

Example 2 — a merge across misaligned boundaries, and the fallback. A different flight, three stored rows:

08DEC–22DEC  1......
13DEC–27DEC  .....6.
07DEC–07DEC  ......7

The Monday and Saturday runs have periods that share no boundary — 08–22 versus 13–27. This is exactly the shape that naive interval logic refuses to touch, and exactly where reasoning about generated dates instead of period edges pays off. Propose the merged row 08DEC–27DEC 1....6. and expand it: Mondays {8, 15, 22} — the 29th falls outside the period — and Saturdays {13, 20, 27}, with no phantom Saturday before the 13th because the first Saturday on or after the 8th is the 13th. The union period introduces no spurious dates; the guard's set-equality check confirms it; the merge stands. Three rows become two — not because the periods aligned, but because the dates did.

The Sunday, fitting no weekly pattern, passes through untouched as 07DEC–07DEC ......7 — a single-date row in period-and-mask costume. Inelegant, and exactly right: that Sunday is a real departure with a real slot, and no packing aesthetic is worth losing it. The fallback isn't an edge-case apology; it's the guard's promise made concrete.

One more design choice: repack as a diff, not a rewrite

The pipeline's output is not "delete everything, insert the new rows." It's a create/delete diff applied onto an undo/redo change stack — the same stack that holds a coordinator's manual edits.

Two things fall out of this. Repacking becomes an undoable action — a coordinator who dislikes the repacked shape presses Ctrl+Z, which matters more than you'd think for trust in an automated rewrite of their data. And the operation composes with concurrent editing instead of trampling it, because it goes through the same conflict-handling path as every human edit.

What I'd generalize from this

A compact representation is a contract with an equivalence class. The moment you choose (period, mask) over a date list, you accept that many encodings mean the same thing — and you will eventually need canonicalization, comparison, and a definition of equality over the meaning, not the encoding. Choose the representation anyway; just budget for the machinery.

Optimize greedily, verify absolutely. Where correctness is binary and the cost of silent loss is high, the winning structure is aggressive heuristics wrapped in a cheap total check. The heuristic can then be as clever or as sloppy as it likes — the guard converts "we believe each stage is right" into "the pipeline cannot emit a wrong answer, only a suboptimal one."

Make automated rewrites undoable. The cheapest way to get humans to trust an algorithm that rewrites their data is to let them un-do it with one key.

I build airport slot coordination and airline schedule systems — IATA telegram processing (SCR/SAL/SMA/SHL/SIR/WCR), schedule algorithms, conflict detection — in Java. Currently relocating to Spain. Find me on LinkedIn.