AML STC expansion
Accomplishment summary review for an AML STC expansion
This review checks the accomplishment summary a supplier submits for an approved model list expansion, confirming that each claim of an objective met is anchored to lifecycle evidence and traced anomalies. A certification specialist reads the summary against the software and hardware records it stands on, looking for the places where the narrative claims coverage the underlying data does not yet show. The output separates well-supported statements from those resting on summary language alone. You receive a gap assessment, an objective-to-evidence map, and a closure plan before the summary goes forward for formal review.
When this review is needed
- The added models change the installation such that the original accomplishment summary no longer describes what was actually done.
- A software or hardware accomplishment summary asserts every objective satisfied and no one has walked those claims back to their records.
- Open problem reports exist and the summary has to state how each is dispositioned for the expanded effectivity.
- The authority expects the summary to reconcile with the lifecycle data before it will accept the expansion.
The problem
An accomplishment summary is a narrative, and a narrative can outrun its evidence. Under expansion, the temptation is to reuse the original summary language and adjust the effectivity, which leaves statements about objective coverage and anomaly disposition describing the first approval rather than the added models. The summary reads complete while the lifecycle records that should back it tell a partial story.
What gets reviewed
- Each objective the summary claims satisfied traced to the lifecycle records that demonstrate it
- Anomaly and problem-report disposition checked against the actual state of each open item
- Reused summary language screened for statements that describe the original approval, not the added models
- Software and hardware level assignments confirmed to match the coverage the summary claims
- Effectivity in the summary reconciled with the models the expansion actually adds
- Lifecycle data references validated so each citation resolves to a real, current document
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 objective the summary marks complete resolves to a verification record, not to prose alone
- Open problem reports are described in the summary with their real disposition state
- The summary's effectivity matches the added-model list rather than the original approval
- Claimed software and hardware assurance levels agree with the evidence depth actually present
- Each lifecycle citation in the summary points to a document that exists and is current
Evidence normally required
- The draft accomplishment summary for the expansion
- The software and hardware lifecycle data the summary references
- The open and closed problem-report log
- The certification basis and assurance-level assignments for the added models
- The original STC accomplishment summary for comparison of reused language
Common discrepancies
- A summary statement of an objective met that traces to no verification record
- Effectivity carried over from the original approval that no longer matches the added models
- An open problem report the summary treats as closed
- An assurance-level claim the lifecycle evidence does not go deep enough to support
What is at stake
When the authority tests a summary claim and the referenced lifecycle data does not support it, the whole summary loses credibility and the review slows to a line-by-line reconciliation. Open problem reports that the summary glossed over become conditions on the added models, and the supplier substantiates them late instead of on its own schedule.
How the work runs
Read summary against basis
Map each objective the summary claims to the certification basis element and assurance level it must satisfy for the added models.
Trace claims to records
Follow each asserted objective to the lifecycle document that demonstrates it and flag the ones that do not resolve.
Reconcile the anomalies
Compare the summary's disposition of each problem report against the actual state in the log.
Plan the closures
List the claims and citations that cannot yet be defended and sequence the work to close them.
What the buyer receives
- A gap assessment naming each summary claim that outruns its evidence
- An objective-to-evidence map tying every asserted objective to a lifecycle record
- A closure plan for the anomalies and citations the summary cannot yet defend
Who uses the output
- Certification leadership judging whether the summary can be submitted as written
- The STC holder defending individual summary claims during review
- Program managers tracking which lifecycle references still need to be closed
How the work fits into the transaction or program
The summary review runs after the lifecycle data for the added models is in hand but before the summary is finalized for submission. It keeps the narrative honest to its evidence, and its closure plan feeds back into the lifecycle work so the summary describes what the records actually show when the authority reads it.
Start with a single asset
Reduce finding cycles by checking the package first.
Regulatory limits
The review reconciles the accomplishment summary with its lifecycle evidence for traceability and accuracy. It does not certify the software or hardware, assign assurance levels, or grant or extend the STC to the added models.
What this review does not cover
- Producing the lifecycle data the summary is missing
- Dispositioning open problem reports on the supplier's behalf
- Making any assurance-level or airworthiness determination
Specific to this review
- An accomplishment summary is a claim document, so a wrong statement in it is worse than a gap in raw data: it asserts something the evidence contradicts.
- Reusing the original summary and adjusting only the effectivity is the most common way an expansion summary ends up describing the wrong models.
- Problem reports that read as closed in the summary but remain open in the log are the disposition errors that become conditions on the added models.
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.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
Can we reuse the original STC's accomplishment summary for the expansion?
Some structure carries over, but reusing the language wholesale is where problems start. The added models change the installation and the effectivity, so each claim has to be tested against the lifecycle data for the models actually being added, not the ones already approved.
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.