Modification status
Modification and STC status review in a shop-visit source file
A shop visit changes configuration, and the modification status report is the claim of what changed. This review verifies each SB and STC listed as embodied, partially embodied, or not applicable against the source file: the accomplishment records, kit and parts evidence, effectivity for the serial number, and the approval or substantiation behind the change. It is run for quality and asset teams at package acceptance. Unsupported embodiment claims and effectivity mismatches are reported line by line.
When this review is needed
- The visit embodied SBs or STCs and the status report must be proven before the configuration record updates.
- Partial embodiments left the visit and their completion state needs precise documentation.
- An STC installed earlier surfaced during strip and its paperwork was not in the incoming file.
- The asset's next operator or registry will re-evaluate the modification status against different acceptance rules.
The problem
Modification status is where configuration control meets paperwork, and shop visits stress both. An SB gets embodied through a kit whose certification arrives with the parts invoice, an STC installation spans cards from two subcontractors, and a bulletin judged not applicable is marked so on someone's reading of effectivity that never gets written down. The report printed at closeout renders all of this as tidy status codes, and the reasoning behind each code is exactly what the file needs and often lacks.
What gets reviewed
- Each modification line on the report traced to accomplishment records in the visit file
- Effectivity verified for the airframe or engine serial number against the SB or STC applicability
- Kit certification and parts evidence located for embodiments consuming modification kits
- STC entries matched to the approval, master data list, and any required flight-manual supplement
- Partial embodiments documented for the exact stage completed and the remaining steps
- Not-applicable determinations checked for a recorded effectivity basis
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
- Accomplishment records describe the embodiment work at the level the bulletin or STC defines
- Serial-number effectivity in the source document includes this aircraft or engine
- Kit part numbers consumed match the modification's parts list and carry release coverage
- STC documentation includes the approval reference and, where required, operational supplements
- Status codes on the report agree with what the accomplishment evidence supports, line by line
Evidence normally required
Common discrepancies
- An SB coded embodied on the strength of a kit purchase, with no accomplishment record in the cards
- A partial embodiment reported as complete because the status system lacks an intermediate code
- An STC discovered installed with no approval documentation anywhere in the delivered file
- Not-applicable entries resting on effectivity reasoning that the source document contradicts
What is at stake
A wrongly claimed embodiment corrupts the configuration baseline that later maintenance, AD applicability, and transaction reviews all rely on. An SB shown embodied without evidence gets challenged at the next transition; a not-applicable call made on bad effectivity reasoning can conceal a directive the aircraft actually owes. Fixing status errors after the configuration record propagates them means correcting every downstream document that inherited the mistake.
How the work runs
Baseline the claims
List every status line the report makes: embodied, partial, and not applicable.
Pull the evidence
Trace each claim to accomplishment, kit, effectivity, and approval records.
Resolve the conflicts
Work unsupported and contradicted lines with the shop while records are reachable.
Certify the report's basis
Deliver the line-verified report and exception schedule for the configuration record.
What the buyer receives
- A line-verified modification status report with per-line evidence citations
- An exception schedule for unsupported, partial, and contradicted entries
- A configuration-record update recommendation for the entries the file proves
Who uses the output
- Configuration and records teams updating the asset's modification baseline
- Quality managers resolving exceptions with the shop before acceptance
- Asset managers presenting modification status to buyers, lessees, or new registries
How the work fits into the transaction or program
Modification status verification protects the configuration baseline that AD applicability reviews and future workscope planning are built on. It draws on the repair review where alterations blur into repairs, and its verified report becomes the reference the next operator's bridging exercise starts from.
Start with a single asset
Confirm release certificates and component traceability are complete.
Jurisdiction-specific considerations
An STC approved by one authority is not automatically valid under another; bilateral agreements and validation procedures under frameworks like EU Regulation 748/2012 govern what transfers and what needs re-approval. Assets changing register mid-life carry modifications approved under several regimes, so each status line is read against the authority whose approval it cites and the registry the aircraft is bound for.
Regulatory limits
The review confirms documentary support for status claims. It does not approve modifications, judge STC or SB applicability where the source data is ambiguous, accept alterations on behalf of any authority, or amend the aircraft's configuration record; those actions belong to design organizations, certifying staff, and the operator.
What this review does not cover
- Physical conformity inspection of embodied modifications
- Obtaining STC validations or approvals from any authority
- Judging the commercial value or desirability of installed modifications
Specific to this review
- Kits are the classic false positive: purchasing evidence exists, the parts are on site, and the embodiment card was never raised.
- Status systems with only embodied and not-embodied codes force partial embodiments into whichever answer is less wrong, and the report inherits the distortion.
- Undocumented STCs found at strip usually date from an owner several transactions back, which is why the discovery record made now determines whether the trail can ever be rebuilt.
- A recorded effectivity basis for every not-applicable call costs minutes during the review and saves the same argument at every future transition.
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). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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.
Frequently asked questions
Why verify not-applicable entries when nothing was done?
A not-applicable code is a claim about effectivity, and it removes the item from future attention. If the reasoning is wrong, the aircraft silently owes a modification or directive that no due list will ever raise again, which makes those entries worth the few minutes each takes to check.
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.