Engine shop visits
Engine shop-visit package review against its source records
An engine shop-visit package summarizes a build; the source records prove it. This review reconciles the delivered package against module assembly records, strip findings, test-cell results, and the release documentation, confirming that the configuration certified out of the shop is the one the underlying paperwork describes. It is performed for lessors, owners, and quality teams at or shortly after acceptance. The finding set identifies each point where the package and its sources diverge.
When this review is needed
- An engine is coming off a performance restoration and the package must be verified before the invoice cycle closes.
- The workscope changed mid-visit and the delivered package may not reflect the final build.
- A lessor is accepting the engine back into the portfolio and needs the file transaction-ready.
- Test-cell margins will support future value claims, so the data behind them has to be in the file.
The problem
Engine packages are compiled from several departments' outputs: the build floor, the test cell, engineering, and the release office, each closing on its own schedule. Workscope changes ripple unevenly through those outputs, so the summary can describe the planned build while the module records describe the actual one. The receiving team gets a thick, well-organized package whose internal contradictions only appear when someone reads it across sections.
What gets reviewed
- Final build configuration cross-read between the summary, module records, and release documents
- Strip findings and workscope changes traced through to their effect on the delivered build
- Test-cell acceptance data checked for completeness and agreement with the certified performance
- Module serial numbers and part positions reconciled across assembly and release paperwork
- LLP sheet consistency with the module records, at the level the trace review then takes deeper
- Open items, deferred work, and carried-over defects stated in the package versus the cards
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 module in the released configuration appears in the assembly records with matching serials
- Workscope deviations approved mid-visit are documented and reflected in the final summary
- Test-cell runs referenced in the acceptance section exist in the raw data with passing results
- The release certificate configuration statement matches the build as the module records describe it
- Nothing certified as accomplished in the summary is contradicted by an open or deferred card
Evidence normally required
- The complete engine shop-visit package as delivered
- Module assembly and disassembly records with serialized part listings
- Test-cell data sheets and the acceptance test summary
- The induction workscope, its revisions, and the commercial change orders
- Release certification issued for the engine and its modules
Common discrepancies
- A module swapped during the build with the summary still describing the original unit
- Test-cell margin quoted in the acceptance letter that cannot be located in the raw run data
- Workscope items invoiced as completed while the corresponding cards show deferral
- Serial-number transpositions between disk sheets and the assembly record for one module
What is at stake
A package that disagrees with itself undermines every number downstream: LLP lives, EGT margin, workscope credit toward the next visit. Discrepancies discovered after the commercial closeout mean reopening an account both sides considered settled, and if the engine trades before the mismatch is found, the buyer's reviewer finds it instead, with the price adjustment flowing back to the seller.
How the work runs
Index the package
Break the delivered package into claims: configuration, workscope, performance, and status.
Cross-read the sources
Check each claim against module records, cards, test data, and releases.
Log divergences
Record every mismatch with the documents on both sides of it.
Support the acceptance
Report in time for resolution inside the acceptance and invoice window.
What the buyer receives
- A reconciliation report mapping the package's claims to their supporting records
- A divergence list, each item tied to the exact documents that disagree
- An acceptance recommendation noting what to resolve before the file is closed
Who uses the output
- Lessor technical managers accepting the engine into or back into the portfolio
- Owner representatives settling the commercial closeout with the shop
- Records leads deciding what enters the asset's permanent file and in what form
How the work fits into the transaction or program
The package reconciliation is the umbrella pass over the engine file: the AD, LLP, and release reviews each drill one seam it exposes. Teams usually run it first on an engine event, because a package that fails reconciliation redirects where the detailed reviews should dig.
Start with a single asset
Confirm release certificates and component traceability are complete.
Jurisdiction-specific considerations
Engine shops release under their own approval scope, and a visit performed under FAA Part 145 for an EASA-registered operator, or the reverse, hinges on bilateral maintenance provisions and dual-release wording. The review confirms the certification language on the engine and module releases matches the register and oversight system the engine is returning to.
Regulatory limits
The reconciliation states where documents agree and where they diverge. It does not certify the engine or any module, validate test-cell performance from an airworthiness standpoint, or release the engine to service; the shop's certifying staff and the operator's acceptance process hold those responsibilities.
What this review does not cover
- Borescope, performance, or any physical assessment of the engine
- Negotiating invoice adjustments arising from the divergence list
- Re-running or validating test-cell calculations independently
Specific to this review
- Mid-visit workscope changes are the root of most package contradictions, because the summary is often drafted from the plan rather than the outcome.
- Module-level releases can be internally correct while the engine-level summary mis-states which modules are installed, and only a cross-read catches it.
- Test-cell raw data is retained on shop systems with finite retention windows; margins not extracted into the package at acceptance can become unprovable.
- The divergence list doubles as a commercial instrument: items on it map directly to invoice lines still open at closeout.
Sources
U.S. Government (eCFR). Maintenance recordkeeping content and approval-for-return-to-service requirements, including 43.9, 43.11, and Appendix B.
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.
Federal Aviation Administration. Completion and use of FAA Form 8130-3, Authorized Release Certificate, for new and used parts.
European Union / EASA. Continuing airworthiness, maintenance records, CAMO responsibilities, and the airworthiness review process in the EASA system.
Frequently asked questions
When should this run relative to engine acceptance?
Start it as soon as the draft package is available, even before formal delivery. Divergences raised while the shop's job file is open and the invoice unsettled get corrected as routine; the same items raised after closeout become negotiations.
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.