Skip to content

Substantiating repairs

Repair and alteration records review within a component-history source file

A repair approval data review builds a map of every repair and alteration in a component's history and tests whether each one stands on approved or otherwise acceptable data. Shop findings, release certificates, installation records, and the serial-number trail supply the repair history; the review then hunts for the engineering basis behind each entry. Operators, lessors, and MRO teams use it when a trace is being assembled, challenged, or priced. The component records lead receives a repair map with an exception list identifying which repairs lack the data, disposition, or approval reference that would let them survive review.

When this review is needed

  • Shop findings reference repairs whose engineering approval was never filed with the component's records.
  • A reviewer has asked for the data behind a specific repair and the answer will set a precedent for the rest of the file.
  • A part with visible rework is entering a transaction and the history must explain every deviation from standard.
  • Records inherited from prior operators list repairs by shorthand codes nobody on the current team can decode.

The problem

Repairs get performed against data that lives with the approving engineer or the shop, while the component's records keep only the outcome. Years later the history says a weld repair or a blend was done, the release references a repair scheme by number, and the scheme itself is nowhere in the file. Distinguishing a repair with retrievable approval from one that was never properly substantiated is the difference between a paperwork errand and a serious finding, and the file alone rarely says which.

What gets reviewed

  • A complete repair and alteration inventory extracted from shop findings, releases, and installation records
  • Each repair matched to its data source: SRM, CMM procedure, approved repair scheme, or field approval
  • Major versus minor classification checked against how the repair was actually processed
  • Approval references on release documents resolved to the actual data they cite
  • Alterations checked for STC or equivalent design approval where the change required one
  • Recurrence and inspection obligations from repairs traced into the maintenance requirements the part now carries

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 repair visible in the history appears on the map, including those known only from a release remark
  • Data cited for each repair exists, is retrievable, and covers the repair as performed
  • Repairs processed as minor would genuinely have qualified as minor under the applicable rules
  • Referenced repair schemes resolve to documents whose scope includes this part and serial
  • Any repair imposing repetitive inspections is reflected in the component's current maintenance requirements

Evidence normally required

  • Shop-visit reports, teardown findings, and work orders across the component's history
  • Release certificates whose remarks blocks reference repairs or deviations
  • The applicable SRM and CMM revisions for the repair periods in question
  • Any repair schemes, engineering orders, or field approvals already on file
  • The component's current maintenance requirements, for repair-driven obligations

Common discrepancies

  • A repair scheme referenced by number on a release, with the scheme document lost when the shop changed hands
  • Blend or rework limits exceeded per the findings report, with no engineering disposition recorded
  • An alteration that changed form or function processed as a repair without design approval
  • Repetitive inspection requirements created by an old repair and absent from the current program

What is at stake

A repair without demonstrable approval basis puts the component's serviceability into question retroactively, and reviewers escalate quickly because the exposure is technical as well as regulatory. Under time pressure a counterparty will discount or reject the part rather than wait for substantiation, and an authority finding on one undocumented repair tends to trigger examination of every other repair in the file.

How the work runs

01

Inventory the repairs

Extract every repair and alteration from findings, releases, and installation records into one list.

02

Chase the data

Resolve each cited approval to a real document and hunt for the basis behind uncited repairs.

03

Classify and date

Test each repair's classification and approval against the rules applicable when it was done.

04

Map and hand over

Deliver the repair map, exceptions, follow-up plan, and program-obligation note.

What the buyer receives

  • A repair map covering every identified repair with its data status
  • An exception list separating retrievable substantiation from genuinely absent approval
  • A follow-up plan naming the engineering data holders worth approaching for each gap
  • A note on repair-driven maintenance obligations the current program should carry

Who uses the output

  • Component records leads folding repair findings into the trace support file
  • Engineering and quality leadership dispositioning the unsubstantiated repairs
  • Asset and transaction managers pricing the part with the repair exposure quantified

How the work fits into the transaction or program

Substantiation work usually follows the release-document review in a component-history effort, because release remarks are where hidden repairs surface. The repair map then informs the maintenance program check, since repairs can carry obligations forward, and the exception list feeds the same retrieval effort as the rest of the trace work.

Start with a single asset

Confirm release certificates and component traceability are complete.

Jurisdiction-specific considerations

What counts as acceptable repair data differs between the FAA system under 14 CFR 43 and the EASA framework, particularly around who may approve data for major repairs and how alterations are classified. A component repaired under one system and now operating under the other can carry approvals that need mapping to the receiving side's expectations rather than assumption of equivalence.

Regulatory limits

The review documents the approval status of past repairs. It does not approve repair data, does not classify repairs on behalf of any authority, and does not determine the component's current serviceability; dispositions belong to the engineering and quality organizations holding that authority.

What this review does not cover

  • Developing or approving new repair data
  • Physical assessment of repair condition on the hardware
  • Regulatory advocacy with authorities over disputed classifications

Specific to this review

  • Release remarks blocks are the richest single source of undocumented repairs; findings reports come second.
  • A repair scheme's document trail often dies with a shop acquisition, while the repair itself remains in service indefinitely.
  • Misclassification is time-sensitive: a repair acceptable as minor under the rules of its day may read as major under current expectations, and the review dates each call.
  • Repetitive inspections created by repairs are the most commonly dropped obligation at operator transitions.
  • The cost split is stark: repairs with retrievable data are administrative work, repairs without it are engineering projects, and the map is what tells them apart.

Sources

Frequently asked questions

Who can fix a repair that turns out to have no approved data behind it?

An appropriately authorized engineering function must disposition it, which can mean recovering the original data from its holder, generating new substantiation, or accepting the part's limitations. The review's contribution is finding these cases early and naming the most promising data holders.

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.