AML STC expansion
Verification traceability for an AML STC model-list expansion
This work verifies that every requirement across an approved model list expansion is closed by real verification evidence of the right kind. It supports avionics and equipment suppliers extending an STC to new models, ahead of formal review. The review walks the verification side of the trace: test, analysis, inspection, and review results are matched to the requirements they are supposed to close, and requirements marked complete with no evidence behind them are surfaced. You receive a gap assessment, a verification trace that holds, and a closure plan for the missing results.
When this review is needed
- Requirements for the added models are marked satisfied and each closure claim has to point to an actual result.
- The verification method for a requirement changed for the new installation and the evidence has to match the new method.
- Test or analysis was rerun for the expanded effectivity and the results need to be tied back to the requirements they close.
- The package is heading to review and the supplier wants no requirement standing open behind a green status.
The problem
Verification status tends to run ahead of verification evidence. A requirement gets marked closed when the test is scheduled or the analysis is drafted, and the status sticks even if the result never lands or lands in a form that does not actually address the requirement. On an expansion, a result proven on the launch model can be reused where it does not apply, so the closure looks sound while the evidence is for a different airframe.
What gets reviewed
- Each closed requirement matched to a verification result of the method it calls for
- Each item of test, analysis, inspection, and review evidence checked against the requirement it claims to close
- Evidence reused from the launch model confirmed to apply to the added installation
- Methods of verification that changed for the expansion reconciled to the new evidence
- Requirements marked complete with no supporting result identified
- Open verification items sequenced into a closure plan for the STC holder
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Every requirement shown as verified points to a specific, retrievable result
- The verification method of the evidence matches the method the requirement requires
- Reused launch-model evidence is applicable to the added effectivity, not merely present
- Analysis and review results address the requirement in substance, not by title alone
- No requirement carries a closed status without a result behind it
Evidence normally required
- The requirements set with verification methods assigned for the added models
- Test reports, analyses, inspection records, and review results for the expansion
- The verification matrix or status list carried from the original STC
- Applicability data for evidence reused from the launch model
- The installation environment for each added aircraft model
Common discrepancies
- A requirement marked verified whose result was never issued
- Launch-model test evidence reused where the added installation differs materially
- An analysis cited as closing a requirement it does not actually address
- A method mismatch where inspection is claimed but test was required
What is at stake
A requirement shown as verified with no matching result is the kind of gap a reviewer finds by sampling, and one such find invites a wider sweep of the closure claims. Reused evidence that does not fit the added effectivity is worse, because it reads as complete until someone checks what was actually tested. Either way the expansion stalls while the real results are produced or re-tied.
How the work runs
Pull the closure claims
List every requirement the expansion marks as verified along with the result it cites.
Match evidence to requirement
Confirm each result uses the required method and addresses the requirement in substance.
Test reuse for applicability
Check evidence carried from the launch model against the added installation environment.
Plan the open verification
Sequence the requirements still owing evidence into a closure plan before submission.
What the buyer receives
- A gap assessment of requirements without adequate verification evidence
- A verification trace linking each requirement to a matching result
- A closure plan for the verification still owed before submission
Who uses the output
- STC holders confirming closure claims will survive a reviewer's sampling
- Certification leadership deciding where verification has to be rerun for the expansion
- Program managers scoping the remaining verification against the schedule
How the work fits into the transaction or program
Verification traceability closes the loop the requirements trace opened. Where the requirements trace confirmed a path exists to evidence, this review confirms the evidence is real and adequate, so it runs after the requirements trace and alongside the qualification and lifecycle-data reviews. Its gaps define the verification work that remains.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
The kinds of evidence FAA and EASA reviewers sample and the depth they probe can differ for the same expansion. The review flags closures that rest on thin or reused evidence, since those are the rows most likely to draw a question from whichever authority looks first.
Regulatory limits
This work confirms verification evidence exists and fits the requirement. It does not accept the evidence on the authority's behalf, make a compliance finding, or grant approval for the expanded effectivity.
What this review does not cover
- Running or rerunning the tests and analyses that close open requirements
- Accepting or approving any verification result
- Any airworthiness determination on the installation
Specific to this review
- Verification status drifts ahead of evidence: a requirement gets marked closed at test scheduling and the status outlives whether the result ever landed.
- Reused launch-model evidence is the quiet failure on an expansion, because it reads as complete while proving something on a different airframe.
- A method mismatch hides in plain sight: a requirement calling for test can show a closed status backed only by inspection or analysis.
Sources
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.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
Frequently asked questions
How is this different from the requirements-trace review?
The requirements trace confirms a requirement is linked to design and to a verification path. This review confirms the verification result at the end of that path is real, of the right method, and actually addresses the requirement. A requirement can pass the trace review and still fail here if its result was never produced or does not fit the added effectivity.
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.