AML STC expansion
Requirements traceability for an AML STC model-list expansion
This work verifies the requirements trace for an approved model list expansion, confirming that every requirement links down to design and up to verification without a broken thread. It supports avionics and equipment suppliers extending an STC to new aircraft models, before the package is submitted. The focus is the requirements that the expansion changed or introduced, especially derived requirements that never make it into an inherited trace matrix. You receive a gap assessment, a trace that holds end to end, and a closure plan for the missing links.
When this review is needed
- An expansion introduced new requirements at the aircraft-installation level that have to link down to design and up to verification.
- Derived requirements were created during the change and may not appear in the trace matrix carried over from the original STC.
- The design changed for the added models and the affected requirements need their trace re-established.
- A reviewer expects a bidirectional trace and the supplier wants the threads intact before the package is opened.
The problem
Traceability degrades quietly across an expansion. Requirements added for a new installation get written into a specification but never wired into the trace matrix, and derived requirements born during design tend to live in engineering notes rather than the formal trace. The inherited matrix looks whole because it covers the original scope, while the expansion sits half-connected underneath it.
What gets reviewed
- Requirements added or changed by the expansion linked down to the design that implements them
- The same requirements linked up to the verification evidence that closes them
- The derived requirements born during design identified and traced to their source and their allocation
- The inherited trace matrix reconciled to the expanded requirement set for coverage
- Orphaned design or verification items reconnected to a parent requirement or flagged
- Broken threads assembled 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
- Each expanded requirement traces downward to a specific design element that implements it
- Each expanded requirement traces upward to verification evidence that shows it is met
- Each derived requirement is captured with its rationale and allocated to a level of the design
- No requirement introduced by the expansion is left absent from the trace matrix
- Verification items and design elements without a parent requirement are identified
Evidence normally required
- The system and item requirements for the added aircraft models
- The inherited requirements trace matrix from the original AML STC
- Design data and allocation for the changed effectivity
- Verification records available for the expanded requirement set
- Derived-requirement rationale from the development record
Common discrepancies
- A derived requirement generated during design that never entered the formal trace
- A requirement added for the new installation with a design link but no verification link
- A verification item that exists but cannot be tied back to a parent requirement
- An inherited matrix whose coverage stops at the original model's requirement set
What is at stake
A trace with dangling requirements gives a reviewer an easy thread to pull, and each unlinked requirement or orphaned verification becomes a finding that reopens the design conversation. Under ARP4754B, a missing derived-requirement trace also weakens the safety argument that feeds off it, so the gap is rarely contained to one row. The expansion waits while the threads are rebuilt.
How the work runs
Assemble the expanded requirement set
Collect the requirements the expansion added or changed, including derived requirements from the development record.
Trace down and up
Link each requirement to the design that implements it and the verification that closes it.
Reconcile to the inherited matrix
Check the carried-over trace for coverage of the full expanded set and find the orphans.
Plan the reconnection
Sequence the broken threads into a closure plan the STC holder can work before submission.
What the buyer receives
- A gap assessment of the requirements whose trace is broken or missing
- A bidirectional trace that holds across the expanded requirement set
- A closure plan for reconnecting the dangling requirements and verification items
Who uses the output
- STC holders confirming the trace will survive a bidirectional review
- Certification leadership judging whether the safety argument is fully supported by trace
- Program managers tracking which links still have to be closed before submission
How the work fits into the transaction or program
The trace sits between the compliance map and the verification evidence. It takes the requirements the map assigned a means to and proves they connect to real design and real verification, so it runs after the map is fixed and feeds the verification review that follows. Weak threads found here shape what verification still has to produce.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both expect requirement-based development for changes at this level, but the depth of derived-requirement rationale a reviewer asks to see can differ. The trace review notes where the record is thin enough that one authority may press for more, so the same expansion holds up on either side.
Regulatory limits
This work verifies that the trace is complete and consistent. It does not approve the requirements, accept the design, or make a compliance finding on the development. Those determinations belong to the authority.
What this review does not cover
- Authoring the missing requirements or design data
- Performing the verification that closes an unlinked requirement
- Any finding of compliance on the development assurance level
Specific to this review
- Derived requirements are the usual break point: they are created during design and rarely make it back into the formal trace on their own.
- An inherited trace matrix can look complete while covering only the original scope, hiding the expansion's unlinked requirements underneath.
- A dangling requirement is a bidirectional problem: it can be missing a design link, a verification link, or both, and each is found by tracing in the opposite direction.
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
Why do derived requirements cause so many trace gaps?
Derived requirements are created during design rather than flowed down from a higher requirement, so nothing automatically pulls them into the trace matrix. They tend to live in engineering notes. The review surfaces them and ties each one to its rationale and its allocation so the trace is genuinely complete.
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.