Multi-jurisdiction fleet modification and STC status transition review

When this review is needed

• STCs embodied under one authority now have to be recognized or validated by others receiving the tails.
• Cabin and avionics modifications accumulated across operators and their approval trail has never been reconciled.
• A modification status report built for one buyer now answers to parallel receiving authorities.
• Service bulletin embodiment was recorded without linking the approval data behind each change.

The problem

A modification recorded as embodied means little to a receiving authority without the approval basis that made it acceptable, and an STC approved on one register does not automatically carry to another. A change effective under a national approval may require validation before a second authority recognizes it, and a service bulletin logged as accomplished without its approval reference leaves the configuration asserting something the records cannot support. Across a fleet, modification history drifts differently on every tail.

What gets reviewed

• Embodied modifications reconciled to the configuration list and the effectivity for each serial number
• STC files assessed for recognition or the validation each receiving authority will require
• Service bulletin embodiment matched to the approval data referenced for each change
• Modifications relying on a national approval flagged where a destination requires validation
• Change-impact records reconciled where one modification affects another's basis
• Modifications that may not transfer mapped to the tail and the approval evidence in question

What gets validated

• Each embodied modification carries an approval basis appropriate to its destination register
• STC recognition or validation is confirmed for every receiving authority the tail is moving to
• Service bulletin embodiment ties to the approval reference rather than resting on the accomplishment entry alone
• Effectivity on each change matches the serial number and the tail's modification history
• A modification that alters another change's basis is reconciled so the configuration stays consistent

Evidence normally required

• The modification status report and configuration list for every tail
• STC files and the approval data behind embodied changes
• Service bulletin embodiment records with their approval references
• The receiving register and validation expectation for each destination
• Change-impact or configuration-control records where modifications interact

Common discrepancies

• An STC embodied under one authority that a receiver requires to be validated before acceptance
• A service bulletin logged as accomplished with no approval reference behind the entry
• A modification recorded against effectivity that does not apply to the serial number
• A national approval basis that a destination authority will not recognize without further data

What is at stake

A modification whose approval a receiver will not recognize can force validation, re-substantiation, or removal, each of which delays acceptance and adds cost. An STC that does not validate onto the receiving register can leave a tail in a configuration the new authority does not accept until the basis is reconstructed. These divergences surface during acceptance, tail by tail, against a delivery date that assumed a clean transfer.

How the work runs

What the buyer receives

• A transition evidence map linking each modification to its approval basis per authority
• A gap list of modifications and STCs that may not carry to a destination
• A document request set for the approval and validation evidence each receiver requires

Who uses the output

• Engineering deciding how to treat a modification a receiver will not recognize as recorded
• Asset managers pricing the validation or rework exposure across the fleet's configuration
• Records teams assembling the STC and approval evidence each receiving authority asks for

How the work fits into the transaction or program

The review runs before handover so modifications with a fragile or non-transferable approval basis are found while the STC holders and approval data are still reachable. Its gap list drives the validation and evidence work that has to finish before each tail is accepted in its recorded configuration.

Jurisdiction-specific considerations

An STC or modification approved by one authority is not automatically valid on another register, and recognition often depends on a bilateral arrangement or a validation step. The review checks each modification's basis against every destination and flags the changes that need validation rather than assuming embodiment transfers with the tail.

Regulatory limits

The review assembles and grades modification and STC evidence so each receiving authority can decide acceptance or validation. It does not approve a modification, grant or validate an STC, or make an airworthiness determination on the installed configuration.

What this review does not cover

• Developing, approving, or validating any modification or STC data
• A physical configuration survey of the aircraft
• Any airworthiness determination on the installed configuration

Specific to this review

• The distinctive risk here is validation: an STC that is fully approved on the outgoing register may require a separate validation before a receiving authority recognizes it, regardless of how the modification physically performs.
• Service bulletin entries fail transition most often for a missing approval reference, because the accomplishment was logged while the pointer to the approval data was not.
• Modifications interact, so a change accepted in isolation can still create a configuration inconsistency once a related modification's basis is reconciled across the fleet.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits