Skip to content

Registry change

Modification and STC status review for a registry change

A registry-change modification status review confirms that the aircraft's embodied modifications and STCs carry an approval basis the receiving authority will recognize after the register changes. It is run for the team preparing the transition, before handover, across the SB embodiments, STC installations, and configuration entries the new authority will examine. The work checks each modification's approval data, reconciles it to the configuration list, and identifies the STCs whose acceptance is not automatic on the new register. You receive a modification status view keyed to the configuration record, a gap list flagging changes that need a validation path, and a request set for the approval files behind them.

When this review is needed

  • An aircraft is changing register and its STCs were approved by an authority the receiving one does not automatically recognize.
  • SB embodiment and modification history has built up across operators without a consolidated configuration record.
  • A modification is claimed on the status report but the approval file behind it has never been verified.
  • A handover date is set and the team needs to know which STCs require a validation path on the new register.

The problem

An STC approved by one authority does not simply become valid on another register; it usually has to be validated, and that path is invisible until the transition forces the question. Modification status reports carry SB embodiments and installations forward across operators, and the approval files that would substantiate them drift out of the record set. The team assembling the change has to prove which modifications hold and identify the ones that need a validation route before the receiving authority asks.

What gets reviewed

  • Embodied SBs checked against their revision, effectivity, and accomplishment evidence
  • STC installations mapped to the approval that would need validating on the new register
  • Approval and substantiation data located for each claimed modification
  • Configuration list reconciled to the modifications the records assert are embodied
  • STCs identified whose acceptance requires a validation path rather than direct recognition
  • Interactions between overlapping modifications resolved against the type design

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

  • Each embodied SB carries accomplishment evidence at the revision and effectivity applicable to the serial number
  • Every STC on the status report has an approval file the receiving authority can review
  • The configuration list matches the set of modifications the records claim are embodied
  • STCs requiring validation on the new register are flagged with the reason recognition is not automatic
  • Overlapping or superseding modifications are reconciled rather than double-counted

Evidence normally required

  • The modification and STC status report
  • SB embodiment records with revision and effectivity
  • STC approval files and installation substantiation
  • The configuration list or effectivity record for the serial number
  • Type design reference for reconciling the embodied changes

Common discrepancies

  • An STC recorded as embodied with no approval file retrievable behind it
  • An SB embodiment logged against a revision that does not apply to the serial number
  • A configuration entry that the status report claims but the effectivity record does not support
  • An STC whose acceptance on the new register requires a validation the file never anticipated

What is at stake

An STC the receiving authority will not accept as-is can force a validation application, removal of the modification, or a return to the original configuration, none of which fit inside a transition timeline discovered late. A configuration entry with no traceable approval leaves the aircraft's design standard in question exactly when the new register is trying to fix it.

How the work runs

01

Rebuild the claimed configuration

Assemble the SB and STC status the records assert for the serial number.

02

Verify each approval basis

Locate the approval file behind every modification and check its effectivity and revision.

03

Test recognition on the new register

Identify which STCs require validation rather than direct acceptance by the receiving authority.

04

Scope the validation work

Flag non-portable modifications and define the path each needs before the change.

What the buyer receives

  • A modification status view tying each embodiment and STC to its approval basis
  • A gap list flagging modifications that need a validation path or lack traceable approval
  • A document request set for the STC files and SB evidence still to be recovered

Who uses the output

  • Certification staff scoping the validation route for STCs the new register will not accept directly
  • Asset managers weighing whether a modification is validated, removed, or reverted
  • Records teams gathering the approval files behind each claimed change

How the work fits into the transaction or program

The modification review runs with the repair, AD, and configuration strands of the registry-change package and often drives the certification workload, because an STC validation is the longest-lead item a transition can carry. Its gap list sets the validation scope before the handover date so the engineering path is opened in time.

Start with a single asset

Confirm the status list matches the underlying evidence.

Jurisdiction-specific considerations

An STC approved by one authority is not directly valid on another register and generally requires validation, and FAA, EASA, and TCCA run that process differently. The review flags each STC's recognition status on the receiving register and the substantiation the validation is likely to need.

Regulatory limits

The review verifies the modification record and identifies the acceptance path for each change. It does not approve or validate an STC, grant any approval, embody or remove a modification, or determine that the resulting configuration is airworthy.

What this review does not cover

  • Preparing or filing an STC validation application
  • Embodying, removing, or reverting any modification
  • Any airworthiness determination on the modified configuration

Specific to this review

  • An STC's validity does not follow the aircraft across registers; recognition on the new authority is a separate step the transition has to plan for.
  • SB embodiment breaks most often at effectivity, where a bulletin is logged as done against a revision that never applied to the serial number.
  • STC validation carries the longest engineering lead in a modification review, so the non-recognized STCs are surfaced before anything else in this strand.

Sources

Frequently asked questions

Do our existing STCs stay valid after the aircraft changes register?

An STC is tied to the authority that approved it and usually has to be validated by the receiving authority to remain valid on the new register. The review identifies which STCs need that path and scopes the substantiation early, because validation lead time rarely fits inside a transition discovered late.

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.