Maintenance tracking
A tracking engine that computes due dates from facts, not memory
Due points are derived exclusively from events — a task performed, a maintenance programme revision, a component installation. How much is left and what the status is gets computed at read time, from current counters and today’s date. Nothing depends on a nightly job that might fail to run.
- Four limit types, status = the worst axis
- A tolerance never moves the next due point
- Forecast from the more conservative of two windows
- Life-limited parts and ADs: zero tolerance, no exceptions
Where the numbers come from
One chain: signature → counter → due point
Signing a techlog entry posts increments on the aircraft counters and on those of every installed component. Due points themselves change on only four events: recording task compliance, activating a new programme revision, installing or removing a component, and correcting a counter. All of it happens in the same transaction as the signature — there is no “it will recompute in a moment” state.
The engine is a pure function covered by golden tests (known cases from real maintenance programmes) and property tests that generate random compliance histories and check invariants — for instance that an incremental recomputation gives exactly the same result as rebuilding everything from scratch.
| Zadanie | Statek | Limit | Termin | Pozostało | Postęp | Status |
|---|---|---|---|---|---|---|
| 100H-PLAT Przegląd 100 h płatowca | SP-GDM | Nalot (block) | przy 450:00 | 37:42 FH | wkrótce | |
| ARC Przegląd zdatności do lotu (ARC) | SP-GDM | Kalendarz | 14.09.2026 | 50 dni | wkrótce | |
| LLP-MR Łopata wirnika nośnego — resurs | SP-GDM | Nalot (block) | przy 2200:00 | 1787:42 FH | dopuszczony | |
| AD-SILNIK Dyrektywa zdatności — zespół napędowy | SP-DGM | Kalendarz | 02.08.2026 | 7 dni | w tolerancji | |
| 12M-WYP Przegląd 12-miesięczny wyposażenia | SP-DGM | — | — | — | brak danych |
Limits
Four limit types, one status
A task has as many axes as the maintenance programme actually gives it. Axes are computed separately, and the task status is the worst of them — not an average, not the first in the list.
| Type | Axis | Remaining | Example |
|---|---|---|---|
| Calendar | Months or days | Due date minus today | The 12-month inspection, ARC validity |
| Hours | Flight time in minutes | Due hours minus current hours | The 100 h inspection, an oil change |
| Cycles | Landings or starts | Due cycles minus current cycles | A part with a cycle life limit |
| Mixed | Two or three axes at once | Per axis; status = the worst one, due = the earliest one | “100 h or 12 months, whichever comes first” |
-
Hours as whole minutes
The whole engine works on integers: minutes and cycles. Decimal hours are the simplest way to be a quarter of an hour short after a year.
-
“Whichever first” and “whichever later”
Both appear in real maintenance programmes, so both are in the engine. A task knows its own rule instead of inferring it from the shape of its limits.
-
End of month
Calendar tasks can use the end-of-month convention — an inspection done on 3 March falls due on 31 March the following year, exactly as the programme says.
Tolerances
A tolerance that does not move the schedule
Using a tolerance must not push the whole cycle forward — otherwise, after a few years, the “100 h” inspection really happens every 115 hours. So the anchor for the next due point is the earlier of two values: the actual compliance, or the planned due point. Work done early counts from the actual date; work done inside the tolerance window counts from the planned due point.
To keep that stable regardless of computation order, the planned due point is stored as a snapshot at the moment compliance is recorded. The result does not depend on when or in what order the engine recomputed anything later — the same history always yields the same due date.
A cumulative mode (tolerance added to the next due point) exists, but it is switched on deliberately per task, when the maintenance programme says so. The default is non-cumulative.
Tasks with no tolerance
Life-limited parts and tasks arising from airworthiness directives carry zero tolerance — the database itself enforces it. Passing the due point means “exceeded” immediately, with no intermediate state.
Statuses
Five states CAMO sees
The statuses are identical on the fleet due list, on the aircraft card and on the pilot screen before a flight. One vocabulary, so that nobody interprets the colours their own way.
-
Serviceable
Margin above the warning threshold configured on the task.
-
Due soon
Margin inside the warning threshold — time to plan a slot, no pressure yet.
-
In tolerance
The planned due point has passed; the margin is still inside the task tolerance window.
-
Exceeded
Beyond tolerance. An exceeded task means the aircraft does not fly until it is done.
-
No data
A task with no compliance history and no anchoring policy yet. The system shows “no data” instead of inventing a due date — an item for CAMO to complete, not a green tick.
Warning thresholds belong to the task (separately for days, hours and cycles), so the 100 h inspection and the ARC expiry do not have to light up at the same moment.
Forecast
When the aircraft will stop
The forecast takes the utilisation rate from two windows, 30 and 90 days, and uses the larger one. The 90-day window smooths out the season; the 30-day window catches an aircraft that has just gone back to intensive flying. Choosing the larger rate is deliberate: the forecast must fall earlier than reality, never later.
An aircraft that sits still gets no hours-based forecast. Instead of a date “four thousand days from now”, you get a no-utilisation flag and the calendar due date — the only axis that keeps running in the hangar. For a brand-new aircraft with no history, the declared annual utilisation is used, clearly marked as an estimate.
Anything beyond a two-year horizon is presented as “more than two years” rather than a specific date. Precision that is not in the data hurts maintenance planning more than its absence.
Dependencies
Tasks that reset other tasks
In maintenance programmes the larger inspection usually contains the smaller one: doing the 100 h resets the 50 h. The engine handles such pairs, but only when the edge is written explicitly in the programme. If the 100 h is to reset both the 50 h and the 25 h, both dependencies must be stated. The lack of transitivity is a decision: nobody discovers after the fact that something reset “by itself”.
The dependency runs one way. Performing the subordinate task never resets the master one — that follows from how compliance is recorded, not from a rule someone has to remember.
Maintenance programme
What happens on an AMP revision
Tasks are matched across revisions by their code, so compliance history survives a programme change. A changed interval is computed from the same anchor, and a removed task drops off the due list without deleting any history.
A new task gets an explicit first-due policy: from aircraft manufacture (the default, most conservative one), from the revision effective date, or from a baseline compliance entered by CAMO — for instance from the previous owner’s records.
If a revision would make a task retroactively overdue, the aircraft is not grounded automatically. The item lands in a bridging report and waits for a CAMO decision — a programme revision is office work, not an operational event.
Components
Components and installation history
Engine, gearbox, propeller, blades, life-limited parts — each has its own counters and its own tasks.
-
A component counter computes itself
Component time is its time at installation plus the airframe increment since. There is no second counter to watch by hand.
-
Moving an engine takes its accessories
Moving an engine to another aircraft carries the whole sub-tree of installed accessories with it, and removal records the counter state.
-
History cannot be deleted
Installation and removal records are append-only. They are the evidence during an airworthiness review and when the aircraft is sold.
-
Life-limited parts have no tolerance
A life limit is hard — the engine knows no exceedance window for it.
Documents
ARC, CofA, insurance, AFM
Aircraft documents carry expiry dates and follow the same logic as maintenance tasks: they appear on the aircraft card, on the due list and in the authority pack. An e-mail alert goes out 60 and 30 days before expiry, and again once the date has passed.
A document is never deleted — withdrawing it means archiving it. The old ARC stays visible in history, because during an airworthiness review it is the evidence of continuity.
Alerts
What arrives by e-mail
Alerts are daily and de-duplicated — the same reason does not arrive fresh every morning. An inbox that shouts stops being read.
- A task approaching its due point: margin below the hour or calendar threshold.
- A task in tolerance and a task exceeded — separately, because these are two different decisions.
- ARC and CofA: 60 days, 30 days and past due.
- Crew qualifications and deferred defects approaching their rectification date.
FAQ
Frequently asked questions
How does the system know the remaining margin if nobody enters it?
Because the margin is not a stored number, it is a subtraction: the task due point minus the current counter, or minus today’s date. The due point comes from the last compliance plus the interval from the maintenance programme, and the counter grows when a techlog entry is signed. Nobody has to “refresh” the due list, because there is nothing to refresh — the number is produced at the moment you look at it.
What about a task with an hour limit and a calendar limit at once?
Both axes are computed independently. The task status is the worse of the two, and the due date is the earlier one. An intensively flown aircraft will hit the hour axis, an idle one the calendar axis, and in both cases you see the right reason. The due list shows which axis is driving.
Can I enter a maintenance programme that is not in any catalogue?
Yes — tasks are entered with limits, tolerances, warning thresholds and the whichever-first/later rule, so an operator programme does not have to match a template. At the start this is usually done through an opening balance from three CSV files (counters, tasks, last compliances), with a dry run that stores nothing and a commit under a mechanic signature.
Will the system issue a CRS once a task is done?
No. The release to service is produced outside the system; when recording compliance you enter its number, the date of the work, the counter state at that moment and who performed it, and the scan goes into the aircraft records. Work orders and issuing a CRS belong to the next phase — until they exist, we say so plainly.
Next
The nearest topics — on the site and in the knowledge base.
On the site
- Electronic techlog
One entry per flight, an electronic signature, immutability and work with no signal.
- Bulletins and ADs
Automatic ingest of SBs, SLs and ADs, review and sign-off, manual route.
- Who it is for
Flying club, ATO/DTO, helicopter operator, owner and CAMO — a working day for each.
In the knowledge base
- Tolerances without drift: how to compute inspection due points
Why inspections creep forward, how anchoring to the planned due point fixes it, and what to do with a task that has an hour limit and a calendar limit at once.
- The ARC and the airworthiness review: an operator's calendar
How an airworthiness review differs from maintenance, what the records review covers, how the operator's year is laid out and what most often derails an ARC date.
- ADs, SBs and SLs: what is mandatory and what is advisory
Airworthiness directives always bind you; manufacturer bulletins only once something makes them binding. Where the line runs, where to source documents across the EU, and how not to confuse an SIB with an AD.
See CamoBook on your own fleet
Thirty minutes, live: a signed techlog entry, the due list for your aircraft type and the audit pack. No sales deck — we talk about your maintenance programme.
or write to pawel@mamcarz.com