Tolerances without drift: how to compute inspection due points

A spreadsheet used to track life limits almost always contains the same mistake. Not in a formula — in an assumption. The next due point is computed from the date the work was actually done rather than from the due point that was planned. The effect is quiet and cumulative: every inspection carried out at the edge of tolerance pushes the whole remaining cycle forward.

Where the drift comes from

Take a task with a 100-hour limit and a 10-hour tolerance.

Cycle	Planned due	Carried out at	Next due without anchor	Next due with anchor
1	100:00	108:00	208:00	200:00
2	200:00	207:00	307:00	300:00
3	300:00	309:00	409:00	400:00

After three cycles the “without anchor” column is nine hours further out than it should be. Nobody did anything wrong, every visit was inside tolerance — and yet the aircraft is flying longer between inspections than the maintenance programme intends. A tolerance meant as a one-off scheduling margin has quietly become a permanent extension of the limit.

The rule that fixes it fits in one sentence: the reference point for the next due is the earlier of the two values — the actual completion or the planned due. Doing the work early moves the cycle forward naturally (the completion becomes the anchor), but using the tolerance buys no extra margin for the future.

There is a practical consequence when transcribing state from paper: if the imported file has no planned due date, the system must declare the assumption openly that the completion date becomes the anchor. That is information for the engineer, not an implementation detail — the first due point after migration depends on it.

Two axes in one task

Most maintenance programme tasks carry more than one limit: 100 hours or 12 months, whichever occurs first. The opposite rule — whichever occurs later — exists too, as do mixed tasks where some limits are in hours and others in calendar time.

For a due list to be useful, every task needs a driving axis: the one that falls first (or last, depending on the rule). It answers “how much longer can I fly”, it drives the status colour and it goes on the printout. A list that shows “37 hours” and “50 days” separately leaves the arithmetic to a human — exactly what was supposed to disappear.

A separate trap is the hour base. A helicopter usually has both a block-time counter and a tachometer, and they do not run at the same rate. If the maintenance programme says “100 h by tach” and the system counts block time, the difference can grow into double-digit percentages. Every hour limit therefore has to point at a specific counter, and the techlog entry has to record both readings. That is not redundant data: it is the only way one fleet can have tasks measured on two different bases.

Forecasting: conservative and honest

“37 hours remaining” is information for an engineer. Planning needs a date. Converting hours into days requires an assumption about utilisation, and two choices decide everything:

• Which utilisation? A 30-day average reacts quickly but swings wildly after a week of downtime. A 90-day average is stable but late. Taking the larger of the two is safer: the forecast falls earlier, and the error points towards an earlier inspection rather than an overrun.
• What about an aircraft that is not flying? Utilisation close to zero produces forecasts like “due in 412 days”. That number looks like knowledge but is an artefact of division. It is more honest to show a “no utilisation” status and forecast nothing.

The same honesty applies to the “no data” status. A task that cannot be computed — because a counter has no starting state or the compliance history is missing — is not a task that is fine. On the due list it has to look like an alarm, because it means a hole in the data rather than spare time.

Where there is no tolerance at all

Tolerance is a property of the task, not a privilege of the organisation — and for some tasks it is zero. That applies above all to life-limited parts and to tasks arising from airworthiness directives. A compliance date stated in a directive is a date, not a suggestion; it cannot be “absorbed into tolerance”, because there is none.

The practical consequence for configuration: tolerance has to be a field on the task, defaulting to zero and set deliberately only where the maintenance programme allows it. The opposite default — one global tolerance for the whole fleet — will sooner or later be applied to an LLP, and that is a mistake nobody sees until the limit has been passed.

A master task resets its slaves

Maintenance programmes contain nested tasks: the 100-hour inspection normally covers the scope of the 50-hour one. If the system does not know that relationship, the 50-hour task stays outstanding after the 100-hour visit — and the engineer closes it by hand with a second record for work that was never separately performed.

The correct arrangement is an explicit master → slave relation: recording compliance with the master task generates compliance for every task inside its scope, with the same date, the same counter state and the same release reference. Each one remains a separate record — a reviewer has to see that the 50-hour scope was accomplished, not infer it from the fact that the 100-hour visit happened.

How to read a due list

Four statuses are enough, provided they are mutually exclusive and defined up front:

• overdue — the due point has passed and is outside the task tolerance; the aircraft does not fly until the work is done,
• within tolerance — the due point has passed but is inside the permitted margin; this needs a conscious decision, not silence,
• due soon — approaching (typically 25 flight hours or 30 days),
• no data — the task cannot be computed.

The due list also has to carry the tasks raised from airworthiness directives and manufacturer bulletins — a document assessed as “applicable” but never transferred into the maintenance programme is tracked by nothing at all.

Plus one process rule: the status has to follow from the data, never from a manual override. The moment somebody can “tick off” a task without recording completion with a date, counter state and CRS reference, the due list stops being a document and becomes a note.

What this means when choosing a system

Three questions worth asking at any CAMO software demo:

1. What happens to the next due point if I carry out the inspection inside tolerance? (An answer of “it moves by however late you were” means drift.)
2. Which counter is the hour limit attached to, and can one aircraft carry tasks on two different hour bases?
3. What does a task that cannot be computed look like? (If it looks green, that is the worst possible answer.)

Everything else is negotiable. Those three decide whether the due list is a document you can base a dispatch decision on.