Skip to content

Engine shop visits

Engine shop-visit package review inside a modification baseline file

An engine shop visit is where configuration actually changes hands: modules are rebuilt, SBs are incorporated, and the engine that returns is documented in the shop-visit package. This review reconciles that package against the modification-baseline sources, checking that module build records, test-cell data, and the released configuration agree with the SB records, embodiment evidence, and configuration-control logs the operator maintains. Fleet and configuration teams commission it after a visit closes or when a baseline must absorb visits performed under prior custody. The output lists every point where the shop's account and the baseline's account of the engine diverge.

When this review is needed

  • A shop visit has just closed and the package must be absorbed into the fleet's configuration records before its details go cold.
  • The baseline inherits engines whose visits were commissioned by prior operators or lessors, with packages of varying discipline.
  • SB incorporations reported by the shop need confirming in the operator's own embodiment and status records.
  • Test-cell acceptance data is being relied on for a marginal-performance engine and the paperwork chain behind it matters.

The problem

The shop documents the visit in its own system, to its own conventions, against the workscope it was given; the operator documents the fleet in another system, against the configuration it believes it has. Between workscope changes mid-visit, parts robbed or substituted during build, and SBs incorporated opportunistically because the module was open anyway, the released engine routinely differs from both the induction plan and the operator's expectation. The package records what happened, but only a deliberate reconciliation transfers that truth into the baseline.

What gets reviewed

  • Module build records read against the configuration-control log's account of what entered and left the visit
  • SB incorporations claimed in the package confirmed into the operator's SB and embodiment records
  • LLP movements during the build, installations, removals, and swaps, traced into the status records
  • Test-cell results matched to the released build standard and to any concessions or deviations noted
  • The released configuration compared with the workscope, with every deviation dispositioned in writing
  • Parts substituted or robbed during the visit followed to their release documentation

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 serial in the release paperwork matches the build records and the operator's configuration log after the visit
  • Each SB the package claims incorporated appears in the operator's status records at the correct revision and scope
  • LLP serials and cycles at release reconcile with the pre-induction status plus the visit's documented movements
  • Test-cell data covers the engine as released, on the dates the build sequence implies, with anomalies dispositioned
  • Workscope deviations carry documented approvals rather than appearing silently in the released configuration

Evidence normally required

  • The complete shop-visit package: induction report, build records, findings, test-cell data, and release documents
  • The agreed workscope and any mid-visit amendments
  • The operator's configuration-control logs and SB status records for the engine
  • LLP status documentation before and after the visit
  • Release certificates for parts introduced during the build

Common discrepancies

  • An SB the shop incorporated opportunistically that never reached the operator's status list
  • A module swap during the visit that left the configuration log describing the pre-visit build
  • Test-cell acceptance run against a build state that a later rework changed before release
  • A robbed part returned to the build with paperwork that skips its brief life in another engine

What is at stake

An unreconciled shop visit leaves the fleet records describing an engine that no longer exists in that form. Downstream, AD and SB status lists inherit the error, LLP sheets carry stale build positions, and the next workscope is planned against wrong assumptions, which surfaces as surprise findings at the following visit. At transaction time, a package that disagrees with the operator's records forces the counterparty to choose which account to believe, and they price for the worse one.

Move from findings to resolution

Move from findings to a documented resolution path.

How the work runs

01

Stage the accounts

Line up the shop-visit package against the operator's configuration, SB, and LLP records for the engine.

02

Reconcile the build

Trace modules, parts, and LLP movements through the visit and compare release state to the baseline's expectation.

03

Verify claims outward

Confirm SB incorporations, test-cell linkage, and deviation approvals against their source documents.

04

Close both sides

Deliver the baseline update set and the shop query list before the visit's context decays.

What the buyer receives

  • A divergence list itemizing every disagreement between the package and the baseline records
  • An update set for the operator's configuration, SB, and LLP records reflecting the visit's verified outcome
  • A query list for the shop covering gaps only the shop can resolve, filed while the visit is still fresh

Who uses the output

  • Configuration managers updating the baseline to the engine as actually released
  • Powerplant engineers planning the next workscope from verified build status
  • Asset managers holding a package that will be resold with the engine at the next transaction

How the work fits into the transaction or program

Shop-visit reconciliation is the intake valve of the modification baseline for engines: the AD, SB, and LLP reviews on the same baseline all consume the build truth this review establishes. Run promptly after each visit it is a routine hygiene step; run late, it becomes forensic work against a shop whose staff and systems have moved on.

Jurisdiction-specific considerations

Shops release engines under their own approvals, FAA repair stations under 14 CFR Part 43 conventions and EASA maintenance organizations under Regulation 1321/2014, and international visits mean the package's release logic may follow a different system than the operator's records. Order 8130-21 shapes what the release documentation looks like on the FAA side. The reconciliation respects both frames: it does not question the shop's release, it verifies that the operator's records correctly absorb what that release says.

Regulatory limits

The review is a records reconciliation. It does not approve or reject the shop's work, does not release the engine or any part to service, does not certify test-cell performance, and does not make airworthiness determinations. Disputes over workmanship or contract compliance are commercial matters outside its scope.

What this review does not cover

  • Technical audit of the shop or witnessing of the build and test
  • Warranty or commercial claims arising from the visit
  • Engine condition assessment or performance engineering analysis

Specific to this review

  • Opportunistic SB incorporation is the most common source of silent configuration drift, because it happens outside the workscope that the operator's records team is watching for.
  • The query window with the shop is short: questions asked within weeks of release get answered from live records, while the same questions a year later go to an archive request queue.
  • Robbed parts create the hardest traces in the file, since their movement between builds is documented in whichever engine's package was open at the time.
  • A test-cell report is only meaningful relative to a specific build state, and rework after test is the detail that most often breaks that linkage.

Sources

Frequently asked questions

Should this run on every shop visit or only before transactions?

Every visit, ideally within the query window while the shop can still answer cheaply. Transaction-driven reviews years later find the same divergences but pay archive-recovery prices for them, and some answers are no longer obtainable 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.