Skip to content

Maintenance program records

Pilatus PC-12 maintenance program records review

This review confirms that a Pilatus PC-12 has been maintained to a current approved program and that the program status the records assert holds up. A records specialist runs it for an owner, buyer, or continuing-airworthiness lead who needs the program history to be coherent rather than a patchwork. It checks the program revision in force against what the aircraft actually followed, reads any task escalation and bridging analysis for a written basis, and confirms tasks tie back to their source instructions. You receive a program-status exception list, a source map from status to the approved program, and a plan to close the revisions or escalations that lack support.

When this review is needed

  • A PC-12 is being sold and the buyer will check that its maintenance followed a current approved program.
  • The aircraft moved between owners or managers and the program in force may have changed mid-history.
  • A task interval was escalated and the analysis behind the escalation has never been confirmed.
  • The aircraft is transferring between the FAA and an EASA program and the histories have to bridge.

The problem

A PC-12 can pass through several owners and managers, each running the aircraft to their own version of the maintenance program, and the records rarely mark clearly where one program ended and the next began. A task escalation may have been applied without the analysis that justified it, and a program revision may have lapsed without anyone updating the status. The program status reads settled while the history underneath it is stitched from more than one basis.

What gets reviewed

  • The approved program revision in force checked against what the aircraft followed over its history
  • Program changes at owner or manager transitions identified and reconciled
  • Task escalations read against the analysis that supports each one
  • Any bridging analysis between programs checked for a written and approved basis
  • Program tasks tied back to the source maintenance instructions they derive from
  • Program status reconciled with the task accomplishment records on file

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

  • The program revision the records claim was current for each period is the one actually in force
  • Each task escalation carries the analysis that justifies the longer interval
  • A change of program at an ownership transition is documented, not inferred
  • Bridging between two programs rests on an approved analysis, not an assumption
  • Program status agrees with the task accomplishment records behind it

Evidence normally required

  • The approved maintenance program and its revision history
  • The maintenance program status the aircraft is tracked against
  • Task escalation and bridging analyses
  • Task accomplishment records and the source maintenance instructions

Common discrepancies

  • A period maintained against a program revision that had already lapsed
  • A task escalation applied with no analysis on file to support it
  • A program change at an ownership transition that the records only imply
  • A bridging step between two programs with no approved basis behind it

What is at stake

Maintenance carried out against a lapsed or wrong program revision undermines the intervals every later task depends on, and an escalation without its analysis can force a return to the shorter interval and the inspections that were deferred. Bridging two programs after the fact, at a sale or a transfer, is far harder than confirming a single coherent history while the source documents are still on hand.

Move from findings to resolution

Move from findings to a documented resolution path.

How the work runs

01

Fix the timeline

Lay out the ownership and management history and the program revisions in force across it.

02

Check the basis

Read escalations and bridging steps against the analyses that support them.

03

Tie tasks to source

Confirm program tasks derive from the source maintenance instructions they cite.

04

Flag and map

List where the history frays and map program status back to the approved program.

What the buyer receives

  • A program-status exception list where the history does not hold together
  • A source map from program status back to the approved program and its analyses
  • A closure plan to recover the missing revisions, escalations, or bridging analyses

Who uses the output

  • Continuing-airworthiness leads confirming the program history before a transfer
  • Asset managers pricing the program coherence the records can defend
  • Records teams recovering the escalation and bridging analyses that came up short

How the work fits into the transaction or program

The program review sets the interval framework that task-card, non-routine, and inspection status all sit inside. It runs before a sale or a transfer so a lapsed revision or unsupported escalation is found before the intervals built on it are relied on, and its exception list drives the recovery of the analyses that hold the history together.

Aircraft-specific considerations

Ownership of a PC-12 often moves between owner-operators and management arrangements, and each transition is a point where the maintenance program in force can quietly change. Program continuity across those transitions is where the history most often frays, so the review reads the ownership timeline alongside the program revisions to find where one basis handed off to another.

Jurisdiction-specific considerations

When a PC-12 moves between an FAA operating rule and an EASA program, its history has to bridge from one program structure to the other, and the bridging analysis is what the receiving system will examine. The review notes where the program history was built to one authority and will need a documented bridge for the other.

Regulatory limits

The review confirms the program history is coherent and supported by its analyses, and flags where it is not. It does not approve or revise a maintenance program, accept the aircraft onto any program, or make an airworthiness determination.

What this review does not cover

  • Authoring, revising, or approving the maintenance program
  • Performing any escalation or bridging analysis for approval
  • Any airworthiness determination on the aircraft

Specific to this review

  • On a PC-12 the ownership timeline and the program history have to be read together, because a change of manager is where the program in force most often changes without a clear marker.
  • A task escalation without its supporting analysis can force a return to the shorter interval, undoing the deferrals it enabled.
  • A lapsed program revision can leave the intervals correct on paper while the basis under them has expired.

Sources

Frequently asked questions

Why read the ownership history to check the maintenance program?

On a PC-12 the program in force can change at each owner or manager transition, and those changes are often not marked in the records. Reading the two histories together is how the review finds where one program basis handed off to another.

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.