An overdue task is not a late one

Due today and overdue are different states, and software that merges them will eventually ground an aircraft that was never out of limits.

Due today is not overdue. The difference is one operator and one grounded aircraft.

Ask a planner what "overdue" means and you get a precise answer. Ask a maintenance tracking system and you often get a looser one, because somewhere in it a comparison was written as "on or before today" instead of "before today". The two read almost identically. They do not behave identically.

#The comparison that decides it

A task due on the fifteenth is not overdue on the fifteenth. It is due. It becomes overdue on the sixteenth. In AerSynx that is not a convention in a document; it is a single function that every screen calls, and it compares strictly:

Next due equals today means due today. Overdue starts the day after.

One function matters more than the rule itself. The same question asked on the fleet dashboard, in the forecast, in the export sent to a lessor and in the nightly alert has to return the same answer, or the record starts disagreeing with itself. That is the failure the rule is actually protecting against.

Every due item across the fleet on one horizon — the same comparison drives each row.
Every due item across the fleet on one horizon — the same comparison drives each row.

#Why merging the two states is expensive

A system that treats due-today as overdue produces a queue that is wrong every single day, in the same direction. The effects are not dramatic, which is why they persist:

  • The overdue count is permanently inflated, so nobody trusts it and everyone opens the list to check
  • An aircraft appears unserviceable on the morning it is still legally serviceable
  • Alerts fire a day early, so people learn to ignore the first alert
  • The lessor receives an export showing an overrun that never happened

The last one is the expensive one. An overrun in a redelivery pack is a conversation with someone's lawyer, and the burden of showing it was a rounding artefact falls on you.

#Limits are not all measured in days

The same care applies where the limit is not calendar based. A task can be limited by flight hours, by cycles, by calendar time, or by several at once, and the first of them to be reached is the one that governs. Comparing a flight-hour limit needs the same strictness as comparing a date, and it needs the value to be a number rather than the text the database returned.

Where calendar and utilisation have to be compared on one scale, the conversion is fixed and written down — a month is 30.4375 days, a year is 365.25. Not because those are elegant numbers, but because two parts of the system using 30 and 30.4375 will drift apart and nobody will be able to say which screen was right.

#What this looks like in practice

Nothing. That is the point. A planner opens the list and the tasks due today are in a different state from the tasks that ran out yesterday, and the count at the top is a number they can repeat in a meeting without opening the list to verify it first.

Keep reading

Five systems, one aircraft

Why we stopped buying tools and built one operation instead: how five disconnected systems produce four answers to the same question, and what one shared aircraft record changes about every module since.

Who can see whose money

When one operator runs several legal entities, a shared workspace becomes a channel between them unless somebody decides, field by field, what crosses.