Modification status
Modification and STC status verified against the source package
The modification status report is the claim sheet of a configuration baseline, and this review is where each line on it earns its place. Working from the source package, a records specialist checks every modification and STC shown as embodied for three things: evidence the work happened, effectivity covering this serial number, and substantiation at the revision claimed. Lines that fail any leg become exceptions, including partial embodiments reported as complete. The configuration manager receives a verified status report marked line by line, with an exception register formatted for the configuration support package.
When this review is needed
- The status report was inherited from a prior operator's system export and has never been checked against documents.
- An AD position depends on SB embodiment credit, so a wrong status line silently breaks AD compliance.
- STCs appear on the report without installation approval evidence or the holder's authorization on file.
- Two systems disagree about a modification's state and the baseline must settle which one is right.
The problem
Status reports drift from the truth in small, quiet steps. A system migration maps embodied to a default value, a multi-part SB gets marked complete when only part one was worked, an STC is entered when installation was merely planned. None of this is visible on the report itself; the report always looks authoritative. Only a line-by-line comparison with embodiment evidence, effectivity data, and substantiation exposes which entries are load-bearing and which are artifacts.
What gets reviewed
- Every SB, STC, and local modification the report shows as embodied, sampled to full depth where risk warrants
- Effectivity of each claim against the aircraft serial number and configuration at embodiment date
- Substantiation held in the source file at the revision each line cites
- Partial and multi-part embodiments, checked for stage-accurate reporting
- STC entries examined for installation approval evidence and holder authorization
- Terminating-action credits that AD positions depend on, flagged for the AD review
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
- An embodiment record exists for each line shown embodied, whether card set, SB accomplishment form, or release document
- Effectivity data covers this serial number, including any configuration precondition the modification assumes
- The substantiation revision in the source file matches or supersedes what the report cites
- Multi-part modifications report the stage actually reached rather than the end state
- Report lines that changed during system migrations reconcile with the pre-migration record
Evidence normally required
- The current modification and STC status report
- SB accomplishment records, STC files, and local modification approvals
- Effectivity notes and configuration-control logs for the serial number
- Migration mapping documents from any system change in the aircraft's history
- The AD status report where terminating-action credits interact
Common discrepancies
- An STC listed as installed with no installation approval evidence anywhere in the package
- Part one of a three-part SB embodied, with the report reading the whole bulletin as complete
- Effectivity that excludes this serial number on a line the report shows embodied
- Lines created by a migration default rather than by any recorded maintenance event
What is at stake
A wrong status line propagates: AD compliance shown against a terminating-action SB collapses if the SB claim fails, maintenance-program applicability follows the reported configuration, and weight and equipment records inherit the same error. In a transaction, one demonstrated false line puts the burden of proof on every other line of the report.
Move from findings to resolution
Move from findings to a documented resolution path.
How the work runs
Freeze the report
Fix the status report version under review and log its provenance, including any migrations that produced it.
Test the three legs
For each line, check embodiment evidence, serial-number effectivity, and substantiation revision independently.
Chase the dependencies
Trace failed lines into AD credits, equipment lists, and weight records that relied on them.
Deliver the verdicts
Hand over the marked-up report, the exception register, and the dependency note as one package.
What the buyer receives
- A marked-up status report with each line rated supported, partially supported, or unsupported
- An exception register naming the failed leg per line: evidence, effectivity, or substantiation
- A dependency note listing AD positions exposed by failed terminating-action credits
Who uses the output
- Configuration managers issuing the baseline on the strength of the verified report
- Continuing-airworthiness engineers whose AD positions ride on the embodiment lines
- Lessor technical teams comparing the report against lease-return requirements
How the work fits into the transaction or program
This strand sits at the center of the modification-baseline review; the task-card, logbook, and equipment-list strands all ultimately serve to prove or disprove lines on this report. Its exception register therefore consolidates findings from the neighboring strands before the configuration support package is assembled.
Jurisdiction-specific considerations
Design-change pedigree differs by system: FAA lines rest on 14 CFR part 21 approvals, with AC 21-40 shaping application practice, while EASA lines trace to Regulation 748/2012 and its design-organization outputs. A modification embodied under one authority and now assessed under the other may need validation or acceptance evidence the original file never contained, and the review flags those lines separately.
Regulatory limits
The review verifies documentation against claims. It does not approve modifications, validate STCs across authorities, determine AD compliance, or make any airworthiness finding; lines it cannot support are reported, never repaired by assumption.
What this review does not cover
- Obtaining new or replacement design approvals
- Physical configuration survey of the aircraft
- Rebuilding the AD status report, which is a separate strand
Specific to this review
- The most damaging status errors involve terminating action, because a single wrong SB line can invalidate an AD position that has been reported clean for years.
- System migrations are the leading source of phantom embodiments; a mapping table applied fleet-wide can mark a modification embodied on serial numbers that never saw the work.
- An STC on the report without the holder's authorization in the file is a transferability problem even when the installation itself was sound.
- Stage-accurate reporting of multi-part SBs matters because the parts often carry different effectivity and different compliance credit.
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 sample to full depth instead of spot-checking a status report?
Spot checks catch random error, and status reports fail systematically: a migration default, a habit of marking multi-part SBs complete, an operator that never filed STC authorizations. Once one systematic pattern shows up, only full-depth review of the affected class of lines establishes the true boundary of the problem.
What happens to AD positions when an SB line fails?
The exception register flags every AD that claimed terminating-action credit from a failed line. Those positions revert to open questions for the AD review strand, which then decides whether alternative evidence exists or the AD position must be reworked.
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.