Skip to content

Engine records at handover

Engine shop-visit records review within a lease-transition records file

An engine shop-visit package should let a reader rebuild the visit: what came in, what was done, what went back together, and how it performed on test. This review applies that standard to the shop-visit records inside a lease-transition records file, reading each package against the utilization statements, acceptance notes, and status data delivered with the aircraft. Discrepancies between the released configuration and the build records, and workscope or test-cell documents missing from the package, become exceptions. The transition lead receives a visit-by-visit account of what the file can defend.

When this review is needed

  • An engine had a performance restoration during the lease and the redelivery conditions put a price on its documentation.
  • The transition file holds a mini-pack where the lease requires the full shop-visit package.
  • LLP or configuration queries at acceptance keep tracing back to a visit whose records nobody has read end to end.
  • Engines were swapped between aircraft mid-lease and the visit packages followed neither airframe cleanly.

The problem

A shop-visit package leaves the shop complete and then gets abridged by everyone who handles it: tracking teams extract the mini-pack, records staff file what planning asked for, and the rest sits in an archive that may or may not follow the engine. The transition file usually holds a version of each package. Whether it holds the version an acceptance standard requires is a question nobody has asked until the transition forces it.

What gets reviewed

  • Each shop visit in the lease term located, with package completeness assessed against the visit's scope
  • Inbound and outbound configuration compared through the build records, module by module
  • Presence and consistency of test-cell results against the release and any performance claims in the status data
  • LLP movements during the visit reconciled with the disk sheets and release certificates in the package
  • Workscope documents matched to what the records show was actually performed
  • Visit-related entries in acceptance correspondence reconciled against the package contents

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 released configuration in the package matches the engine's current build as the status system reports it
  • Every module opened by the workscope has build records covering its reassembly
  • Parts installed at the visit carry release certificates that match the build record serial numbers
  • Test-cell acceptance data is present, complete, and consistent with the release date
  • Utilization at induction in the package agrees with the operator's statements for that date

Evidence normally required

  • Shop-visit packages for each visit during the lease, as delivered in the transition file
  • Engine status data covering configuration, LLP status, and time and cycles since visit
  • Utilization statements bracketing each visit's induction and release dates
  • Acceptance notes and the open-item tracker entries touching the engines

Common discrepancies

  • A package that documents the release configuration and skips the disassembly findings that justified the workscope
  • Module build records present for two of the three modules the workscope opened
  • Test-cell sheets referenced in the release paperwork and absent from the delivered file
  • A serial number installed per the build record that never appears in the release-certificate set

What is at stake

A visit that cannot be documented to its claimed workscope stops supporting the build standard the asset is being accepted and valued against. Configuration breaks discovered late force reconciliation under deadline, while the releasing shop's archive, the cheapest recovery source, grows harder to reach with every year and every subsequent visit. Engine exceptions also carry the largest single-item weight in most transitions, so they dominate the negotiation once raised.

Move from findings to resolution

Move from findings to a documented resolution path.

How the work runs

01

Locate the visits

Establish the visit history for the lease term and pull each package as delivered.

02

Read each package

Work through workscope, findings, build records, releases, and test data for completeness and agreement.

03

Reconcile the build

Compare released configuration and LLP movements against current status and the certificate set.

04

Grade and report

Classify each package complete, recoverable, or unsupported and route recovery to the releasing shops.

What the buyer receives

  • A per-visit exception report grading each package complete, recoverable, or unsupported
  • A reconciliation of released configuration to current status, with breaks identified
  • A recovery list directed at the releasing shop and prior custodians for each missing element

Who uses the output

  • Transition leads defending workscope and build-standard positions at acceptance
  • Powerplant engineers confirming the configuration the receiving operator will manage
  • Records staff pursuing package elements while the releasing shop still holds its copies

How the work fits into the transaction or program

Engine findings feed three places at once: the LLP strand, which needs the build records; the configuration picture the receiving operator loads; and the open-item tracker where visit exceptions get negotiated. Running the shop-visit review early protects the recovery window at the releasing shop.

Jurisdiction-specific considerations

Shop visits are released under the regime of the performing shop, which over a lease can differ from the regime managing the aircraft. Packages therefore mix FAA dual releases, EASA Form 1 releases, and national variants, and the review reads each against its own issuing rules rather than one template. Recordkeeping obligations on the operator side sit under 14 CFR 91.417 and Regulation (EU) 1321/2014 respectively.

Regulatory limits

The review evaluates package completeness and internal consistency. It does not judge workscope adequacy, approve any build configuration, issue or validate release documents, or determine the airworthiness of the engine or the aircraft.

What this review does not cover

  • Borescope, test-cell, or any physical assessment of the engine
  • Engineering judgment on workscope sufficiency
  • Negotiating commercial outcomes tied to visit documentation

Specific to this review

  • Shops archive supporting data on their own schedules, and recovery gets harder after the engine's next visit anywhere else.
  • Mini-packs circulate because they satisfy day-to-day tracking; acceptance standards read the full package, and the difference surfaces only at transition.
  • Configuration breaks concentrate at module swaps, where a serviceable module arrives with its own history and the package documents only the installation.
  • The least-copied element of any package is its test-cell data, and it is the first thing a cautious acceptance team asks for.

Sources

Frequently asked questions

The shop that did the visit still has the records. Why not simply ask them for everything?

Blanket requests are slow and often refused. A package-level exception list turns the request into specific documents with dates and serial numbers, which shops answer faster, and the review establishes what is already in hand so nothing gets requested twice.

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.