Approved-basis alignment
Maintenance program records review inside a component-history source file
A maintenance program records review tests whether the program status carried in a component-history file still matches the approved basis it claims to follow. The due list's tasks and intervals are compared against the program documents, revision history, and the operating records that drive each next-due figure, with installed-part lists and release records supplying the component's actual state. Operators, lessors, and MRO teams order this check when program alignment is questioned during a trace, audit, or transaction. The component records lead receives an exception list identifying tasks tracked to the wrong interval, basis, or utilization, formatted for the trace support file.
When this review is needed
- The component moved between operators whose programs differ and the due list was migrated rather than rebuilt.
- Program revisions or escalations were adopted and it is unclear which tracked tasks absorbed the change.
- An audit sampled the due list against the program and found mismatches worth bounding.
- A transaction requires demonstrating that the part has been maintained to an identifiable, approved basis throughout.
The problem
Tracking systems outlive the program decisions encoded in them. An interval entered a decade ago under one operator's approved program persists through migrations, escalations, and ownership changes, while the paperwork explaining why it was set sits in an archive no one consults. The due list keeps generating plausible dates, and nobody notices the basis has drifted until a reviewer asks which approved program a specific interval comes from and the answer takes a week to fail.
What gets reviewed
- Every tracked task on the component due list mapped to its clause in an identified, approved program
- Interval values compared across the due list, the program document, and the revision in force when each was set
- Escalations and program changes traced to their approval and to their adoption in the tracking system
- Utilization inputs behind each next-due figure reconciled with the operating records in the file
- Requirements created by repairs, ADs, or modifications checked for presence on the due list
- Applicability of the program confirmed for the component's actual configuration and operating context
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Send a representative, redacted record set and we will scope the review.
What gets validated
- Each due-list interval matches the approved program revision the operator was entitled to use at the time
- Escalated intervals carry the approval record that authorized the escalation for this operator and part
- Next-due calculations reproduce correctly from documented utilization, with no silent gap-filling
- No requirement imposed by a repair, directive, or modification is absent from the tracked set
- Migrated tasks retain their compliance history rather than restarting their intervals at migration
Evidence normally required
- The current component due list and tracking-system task records
- The approved maintenance program documents and their revision history across the relevant operators
- Escalation approvals and program-change records
- Utilization and operating history supporting next-due calculations
- The component's AD, repair, and modification records, for derived requirements
Common discrepancies
- Intervals inherited from a prior operator's escalated program that the current operator holds no approval for
- A migrated task whose compliance history reset, silently pushing its next due beyond the real requirement
- Repair-imposed inspections recorded in the repair file and never entered into tracking
- Next-due figures computed over a utilization gap bridged by assumption instead of records
What is at stake
A task tracked to the wrong interval is either wasted maintenance or, in the direction that matters, a missed requirement that surfaces as an overdue item the moment the correct basis is applied. Misalignment discovered during a transaction reads as a systemic control failure rather than an isolated error, and repairing trust in the rest of the file costs far more than the original mismatch.
How the work runs
Identify the basis
Establish which approved program and revision governed the component through each ownership period.
Map the due list
Tie every tracked task to its program clause, escalation approval, or derived-requirement source.
Recompute the dues
Rebuild next-due figures from documented utilization and compare with the system's output.
Deliver the alignment file
Hand over the alignment report, exceptions, and the exposure-ordered corrective worklist.
What the buyer receives
- A task-level alignment report mapping every tracked item to its approved basis
- An exception list for intervals, histories, and requirements that fail the mapping
- A corrective worklist ordered by compliance exposure, from overdue-risk items downward
Who uses the output
- Component records leads incorporating program findings into the trace support file
- Continuing-airworthiness and maintenance leadership correcting the tracking system
- Auditors and transaction reviewers, indirectly, through a due list that maps cleanly to its basis
How the work fits into the transaction or program
Program alignment closes out a component-history review: the AD, repair, and release work establish what happened to the part, and this review establishes whether its future obligations are tracked correctly. Findings flow to the tracking-system owners for correction, and the alignment report becomes the reference the next audit or transaction starts from.
Start with a single asset
Confirm release certificates and component traceability are complete.
Jurisdiction-specific considerations
Program approval mechanics differ between systems: US operators work under frameworks such as the recordkeeping requirements of 14 CFR 121.380 and 135.439 alongside their approved or accepted programs, while EASA operators maintain to a program managed under Part-M or Part-CAMO with its own escalation controls. A component crossing between them can carry intervals legitimate under one system and unapproved under the other, which is exactly the drift this review is built to catch.
Regulatory limits
The review reports alignment between records and basis. It does not approve maintenance programs or escalations, does not extend or defer any task, and does not relieve the operator or CAMO of its program-management obligations; corrections are made by the organizations holding those approvals.
What this review does not cover
- Developing, revising, or seeking approval for maintenance programs
- Performing or scheduling the maintenance tasks themselves
- Reliability analysis or optimization of program content
Specific to this review
- Interval drift is invisible to daily operations because the tracking system keeps producing internally consistent dates from an inconsistent basis.
- Escalation approvals are operator-specific; the interval travels with the data migration, the approval does not.
- Task-history resets at migration are the quietest failure in the set, because the next-due date they produce looks generous rather than wrong.
- Derived requirements from repairs and directives fail differently than program tasks: they were never in the program document, so program-to-list comparison alone misses them.
- The cheapest moment to prove program alignment is before a transaction names it as a condition; after that, every finding carries deal leverage for the other side.
Sources
U.S. Government (eCFR). Air carrier maintenance recordkeeping and retention requirements under Part 121.
U.S. Government (eCFR). Maintenance recordkeeping and retention requirements for Part 135 operators.
European Union / EASA. Continuing airworthiness, maintenance records, CAMO responsibilities, and the airworthiness review process in the EASA system.
International Civil Aviation Organization. International standards for aircraft operation, including maintenance program and recordkeeping expectations.
U.S. Government (eCFR). Records an owner or operator must keep, including total time in service, current status of life-limited parts, and AD compliance.
Frequently asked questions
Our tracking system was audited recently. Would this find anything new?
System audits usually test process controls and current data entry. This review tests inherited content: intervals and histories set years ago under other operators and programs, which routine audits sample lightly if at all.
Relevant glossary terms
Related pages
Where this fits
Talk to an engineer who has done this work
We will walk through your current state, the records or evidence involved, and a scoped first engagement.
Talk through the aircraft, records, evidence, deadline, and next useful step.