Program alignment
Maintenance program records review against modification-baseline sources
Modifications change what an aircraft is, and the maintenance program must change with it: STCs bring instructions for continued airworthiness, SBs alter or retire tasks, and equipment changes shift which program items apply. This review reads the maintenance program status against the modification-baseline sources, checking that the task list, intervals, and applicability rules reflect the configuration the SB records, STC files, equipment lists, and configuration-control logs describe. It is run for fleet and configuration managers when a baseline is declared, a program is bridged, or modification campaigns have outpaced program revisions. You receive an exception list of program lines that no longer match the approved basis or the flying configuration.
When this review is needed
- STCs have been embodied across the fleet and nobody has audited whether their ICA tasks all entered the program.
- The program was bridged from another operator's basis and modification-driven differences were handled by assumption.
- Task intervals in the tracking system have drifted from the approved program document through successive revisions.
- A baseline declaration or authority audit will test the chain from configuration to program to tracked task.
The problem
The maintenance program and the modification history are maintained by different teams on different cycles. An STC embodied in March brings ICA with inspection tasks; the program revision that should absorb them lands months later, if the engineering order ever flags them at all. Meanwhile equipment removed by modification leaves its tasks running as harmless waste, and equipment added waits for tasks that do not exist yet. The tracking system dutifully executes whatever list it holds, which is how a program can be fully compliant with itself and wrong about the aircraft.
What gets reviewed
- ICA from every embodied STC traced into the program as tasks with correct intervals and applicability
- SB-driven task changes, additions, retirements, and interval revisions, reconciled between SB records and the program
- Program applicability rules checked against current equipment lists and effectivity notes per tail
- Tracked-task intervals compared line by line with the approved program document, catching migration and revision drift
- Tasks orphaned by removed or superseded equipment identified for program action
- The program's revision history read against the configuration-control log for modifications that never triggered a revision
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
- Every ICA document among the STC files has each of its maintenance requirements matched to a live tracked task or a documented disposition
- Task intervals in the tracking system equal the approved program's intervals, with any escalations traceable to an approval
- Per-tail applicability in the program agrees with each tail's equipment list and modification status
- No SB record marked embodied carries program actions that remain unimplemented
- Every program revision cites its driver, and every configuration change that demanded a revision has one
Evidence normally required
- The approved maintenance program document and the tracking system's task export
- STC files with their ICA sections, and SB records with program-affecting content
- Current equipment lists and effectivity notes for the tails in scope
- Configuration-control logs spanning the period under review
- Program revision history and any bridging documentation from prior operators
Common discrepancies
- An embodied STC whose ICA inspection tasks never entered the tracking system, discovered years after embodiment
- Intervals that diverged from the approved program during a tracking-system migration and were never reconciled
- Tasks still running against equipment a modification removed, alongside missing tasks for what replaced it
- A bridged program carrying the prior operator's applicability assumptions into a differently modified fleet
What is at stake
Missing ICA tasks are latent compliance findings: the obligation attached when the modification was embodied, whether or not the program caught up, and an authority or incident review will read it that way. Interval drift compounds quietly, since each drifted task misses its approved timing by a little more each cycle, and unwinding years of drift can require authority engagement. Orphaned tasks waste hangar hours, but their real cost is the false confidence of a green tracking dashboard sitting on a misaligned program.
Move from findings to resolution
Move from findings to a documented resolution path.
How the work runs
Assemble the chain
Gather the approved program, the tracking export, and the verified modification baseline as the three objects to reconcile.
Trace obligations in
Follow every ICA and SB program action from the modification records into the task list.
Audit the list back
Check each tracked task's interval and applicability against the approved document and the configuration.
Package for revision
Deliver categorized exceptions and the action package aligned to the operator's approval route.
What the buyer receives
- An exception list separating missing tasks, drifted intervals, wrong applicability, and orphaned tasks
- An ICA compliance matrix mapping each STC's requirements to their program implementation
- A program-action package the operator can take into its next revision and, where needed, to its authority
Who uses the output
- CAMO and program engineers preparing the revision that closes the exceptions
- Configuration managers completing the baseline's program dimension
- Quality and compliance staff who would rather self-identify these findings than receive them
How the work fits into the transaction or program
This review is where the modification baseline meets ongoing operations: the AD, SB, and equipment reviews establish what the aircraft is, and this one confirms the aircraft is being maintained as that thing. It typically runs last in a baseline effort because it consumes the verified configuration the earlier reviews produce, and its exceptions flow directly into the operator's program revision process.
Jurisdiction-specific considerations
Program approval mechanics differ: FAA operators run continuous airworthiness maintenance programs under frameworks like 14 CFR 121.380 recordkeeping, while EASA operators hold approved aircraft maintenance programmes under Regulation 1321/2014 with CAMO obligations around revision and effectiveness review. ICAO Annex 6 sits behind both. The practical divergence is in how interval escalations and ICA incorporation get approved, so the review states each exception in terms of the approval route the operator's own system requires.
Regulatory limits
The review compares records and identifies misalignments. It does not approve maintenance programs or revisions, does not grant interval escalations, does not determine compliance with the operator's approval, and does not perform the CAMO's program-effectiveness review. All program changes proceed through the operator's approval processes and authority.
What this review does not cover
- Authoring the program revision or the engineering orders that implement it
- Reliability analysis or optimization of task intervals
- Negotiation of escalations or alternative means with the authority
Specific to this review
- ICA incorporation is the weakest link in most modification processes because the embodiment closes in one department and the program obligation opens in another, with no single owner of the handoff.
- Interval drift is almost always a migration artifact: each system conversion rounds, remaps, or re-baselines a few intervals, and three migrations later the approved document and the tracking system disagree materially.
- Orphaned tasks are the cheapest finding to fix and the most useful diagnostic, since each one marks a configuration change the program process failed to see.
- Bridged programs inherit invisible assumptions, and the modification profile is where donor fleet and receiving fleet differ most.
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 is audited annually. Would it not catch this?
Routine audits typically verify that the system executes its task list correctly. The exceptions this review finds live one level up, in whether the task list itself still matches the approved program and the modified configuration. That chain crosses department boundaries, which is why it escapes list-level audits.
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.