The Aircraft Is Serviceable. The Hard Part Is Proving It on a Tuesday

Airworthiness is a claim, not a condition

The aircraft is fine. The work was done properly, by someone competent, with the right part. And yet the aircraft does not go, because the release certificate for that part is in a folder in a different country, or the certifying engineer's approval scope was never recorded against the task, or the component arrived with a history that nobody transcribed into the record.

Nothing is wrong with the aeroplane. Everything is wrong with the claim.

This is the distinction most maintenance systems quietly blur. Airworthiness is not a state an aircraft is in, like fuelled or parked. It is an assertion the operator makes, continuously, about an asset that is changing continuously — and an assertion is worth what the evidence behind it is worth at the moment somebody asks. Under the applicable airworthiness regimes, the aircraft and its records are effectively one object. Damage the records and you have damaged the aircraft.

The two questions a due list does not answer

Aircraft maintenance tracking software is almost universally built around one question: what is due. That question is necessary, and it is also the easy one. The two questions that actually decide whether an operation runs are different. What does this flight consume. And can I show, on demand, why this aircraft was released.

Maintenance limits are consumed by flying, not by the calendar

An approved maintenance programme is, in the end, a set of limits. Every one of them is being consumed, and flying is the act of consumption. The reason continuing airworthiness management is harder than it looks is that the limits are not all denominated in the same currency, and the currencies do not run at the same rate.

Why two aircraft on the same programme hit different limits first

The practical consequence is that the binding constraint moves. Two aircraft of the same type on the same programme will not hit the same wall first. The one flying training circuits is limited by cycles; the one doing long charter sectors by hours; the one parked between seasonal contracts by calendar, its maintenance bill arriving despite having earned nothing.

Which means the maintenance due list — the artefact every system produces and every planner opens first — is a statement about the past unless it knows something about the future. A list that reports remaining hours without reference to how those hours are about to be spent is describing a position, not a trajectory.

Maintenance forecasting is a scheduling question in engineering clothes

Knowing what is due is arithmetic. Any competent system does it. The question that changes decisions is narrower and much less commonly answered well: what will become due before the next realistic opportunity to do it, given the utilisation actually planned.

What a forecast has to know before it is worth acting on

Three things have to be true for that answer to be worth acting on. The forecast has to use planned flying rather than a fleet-average assumption, because averages are precisely wrong for the aircraft that matter. It has to know where the aircraft will be, since a check can only happen where the capability, the parts and the approval exist. And it has to be recomputed when the schedule moves, which it will, for commercial reasons that have nothing to do with engineering.

Why maintenance planning and scheduling cannot be separate systems

This is why maintenance planning software and scheduling cannot be genuinely separate systems, even in operations where maintenance and scheduling are properly separate departments with different reporting lines and different incentives. The moment they hold their own copies of utilisation, they begin to plan against different futures, and the divergence is discovered at the worst possible time. It is the same fragmentation problem that afflicts the rest of flight operations, with the added property that here it is expensive in two directions: maintenance done early wastes remaining life, and maintenance discovered late grounds an aircraft that was sold. The test of a forecast is not its accuracy in isolation. It is whether a planner and a commercial scheduler can negotiate against the same projection without first arguing about whose numbers are right.

Deferred defects and MEL management are operational, not clerical

Aircraft defect management is where the records stop being a historical archive and become a live constraint on flying. A defect raised on arrival is either rectified before the next departure or deferred, and deferral is routinely treated as a filing decision: categorise, make the entry, dispatch the aircraft.

A deferral is three things, and only the first lives comfortably in a record. It has an expiry, because the rectification interval for its category starts running immediately. It usually has an associated procedure — something the crew or maintenance must do for the deferral to remain valid. And it frequently carries an operational limitation on how the aircraft may be used.

When a limitation has to reach the planner, not just the log

That third element is the one that fails. A limitation living only in the technical log has reached the aircraft but not the operation. The planner assigning tails for next week does not see it. The scheduler moving the aircraft onto a different route does not see it. The crew see it at the aircraft, which is the last useful moment and usually too late. A deferral is only genuinely managed when the constraint it imposes is visible to the people making decisions that the constraint invalidates — which means it belongs on the movement board, not only in the record.

What a rising deferral count says about maintenance capacity

Expiries deserve the same treatment. A rectification interval that runs out is not a paperwork problem found by an auditor; it is an aircraft that cannot depart, found by a dispatcher. And in aggregate, a rising count of open deferred defects is one of the most honest signals a fleet produces about whether maintenance capacity is keeping up — a signal few operators read, because deferrals are held per aircraft and never summed.

Airworthiness directive compliance: applicability is the hard part

AD and SB compliance is usually described as a records problem, and the description is wrong in an instructive way. Recording compliance is straightforward once you know an item applies. Establishing whether it applies is the work.

Why applicability is harder than compliance

Applicability is rarely a property of the type. It is a property of this serial number in this configuration: a serial range, a part number that may or may not be fitted, a modification embodied or not embodied, sometimes a threshold in accumulated hours or cycles, sometimes an earlier directive superseded by a later one with different terms. Two aircraft of the same type in the same fleet can sit either side of the line, and the aircraft that was outside the applicability range last year can move inside it when a component is changed.

That is what makes airworthiness directive compliance a standing reconciliation rather than a task. The set of issued directives changes; the configuration of the aircraft changes; the question is the intersection of the two, re-evaluated whenever either side moves — which, on a fleet with components rotating between airframes, is continuously.

Recurring inspections belong in the due list, not the history

Recurring inspections extend the same problem into the future. A terminating action closes a directive; a recurring requirement joins the maintenance programme permanently and starts consuming its own limits alongside everything else. An operation that treats recurring AD requirements as compliance history rather than as live items in the maintenance due list has quietly split its programme into two lists that nobody reconciles.

Component life tracking, and parts that carry their own histories

An airframe is not a single object with a single set of numbers. It is an assembly of components, many of which have lives of their own, and a good number of which will not finish their lives on this aircraft.

A component removed serviceable from one airframe and fitted to another takes everything with it: accumulated hours and cycles, its shop visit history, its remaining life against a hard time limit, and, where the applicable regime requires it, traceability back to manufacture. Component life tracking is therefore not a subsidiary function of aircraft tracking. It is a second set of records with its own continuity requirement, joined to the airframe records only at fitment and removal.

Where component histories quietly drift

Those joining moments are where the record breaks. A part moves during a night shift, and the accumulated life is carried across on the basis of a number somebody wrote down. Every transfer is an opportunity for the component history to drift, and the drift is silent, because nothing about a component with understated hours looks wrong until it is examined.

It gets examined at the worst possible moment. Nobody audits component traceability in a quiet week. It is audited during a sale, during a lease return, during the transfer of an aircraft between operators — occasions where the operator has already committed commercially and has the least leverage to negotiate about what the records do or do not show.

The dual-entry problem: one flight, recorded twice

Here is a small thing that costs more than almost anything else on this list. The same flight is recorded at least twice. The crew record it in the technical log or journey record. Engineering records it against the airframe and its components. In most operations there is a third capture, in the scheduling or billing system, because someone has to invoice for it.

Three captures of one event, made by different people, at different times, for different purposes. They disagree, because block time and airborne time are different quantities and are not always labelled clearly; because one system rounds to the minute and another to the tenth of an hour; because a diversion or a return to stand produces a cycle count that depends on your definition; and because transcription from paper fails at a rate that is small per entry and relentless in aggregate.

Why a few minutes a sector matters over a year

Individually the discrepancies are trivial. Systematically they are not. A consistent few minutes per sector, unnoticed, accumulates over a year of dense utilisation into a meaningful drift against every hours-based limit on the aircraft. Drift in one direction means maintenance performed earlier than required, which is remaining life thrown away. Drift in the other means a limit exceeded, which is a finding, an investigation and a conversation about the integrity of the whole record set.

The immediate cost is duller and easier to measure: somebody spends part of every week making two numbers agree. That reconciliation is pure overhead. It produces no engineering value, it is invisible in every budget, and it exists solely because aircraft utilisation tracking was allowed to happen in more than one place.

Aircraft technical records are an asset with a price

Technical records are usually managed as a compliance obligation. They are also part of the value of the aircraft. Two identical airframes with identical maintenance histories are not worth the same money if one can evidence that history and the other cannot.

That changes how the work should be resourced. The discount applied to an aircraft with gaps is not proportional to the size of the gap: a missing release for one component can put a question mark over a far larger scope of work, because the buyer's surveyor is not assessing that component — they are assessing whether this operator's records can be relied upon at all.

What is almost never found, in these exercises, is maintenance that was not done. What is found is maintenance that was done properly and evidenced badly. Reconstructing it years later means chasing a maintenance organisation that has since been sold, an engineer who has retired, a supplier record that was never digitised. That is the expensive way to discover what was never captured, and it is expensive precisely because each missed capture cost almost nothing at the time.

What separates a maintenance system from a register

Every maintenance product will show you a due list. That has stopped being a distinguishing feature. These are the questions that still separate a system that runs an operation from one that documents it afterwards:

• Does the forecast use the utilisation actually planned for this aircraft, or a fleet average that is wrong for exactly the tails you worry about?
• When the schedule changes, does the maintenance projection change with it, without anyone re-entering anything?
• Does an operational limitation from a deferred defect reach the planner and the crew, or only the record?
• Can you see, for a given serial number in its current configuration, which directives and service bulletins apply — and which of them recur?
• When a component moves between airframes, does its history move with it as data, or as a number someone copies?
• How many places is a single flight's hours and cycles entered, and who reconciles them?
• If an auditor asked today why a specific aircraft was released on a specific Tuesday, how long would the answer take to assemble?

It is also why we do not treat maintenance and scheduling as separate concerns in Aerotalon. A due list that cannot see next week's flying is describing the past.

That last one is the whole argument compressed. Every operation can eventually answer it. The difference between a good maintenance system and a register is whether answering it is a query or a project — and whether the answer is found, or reconstructed.