AML STC expansion
Configuration management review for an AML STC model-list expansion
This work reviews the configuration management evidence behind an approved model list expansion, confirming that the data being submitted matches the controlled baseline it claims. It serves avionics and equipment suppliers extending an STC to new models, before submission. The review checks baselines, revision histories, and release records so every artifact in the package traces to a controlled version, and finds where a submitted item has drifted from its baseline. You receive a gap assessment, a configuration-to-evidence reconciliation, and a closure plan for the items that do not line up.
When this review is needed
- The expansion pulls together data from several sources and each artifact has to trace to a controlled baseline.
- Software or hardware revised during the change and the package has to reference the released revision, not a working one.
- Multiple aircraft models share evidence and the configuration has to show which version applies to which model.
- A reviewer will check that submitted reports match the controlled configuration and the supplier wants that reconciliation done first.
The problem
Configuration control is where an expansion package quietly comes apart. Data is assembled from a long program history, and a report that was current when it was written can be superseded by a later baseline while the older copy still sits in the package. Software and hardware get revised, plans get updated, and the version referenced in one artifact stops matching the version released in another. The package looks internally consistent until someone checks each item against the configuration index.
What gets reviewed
- The configuration baseline for the expansion identified and its scope confirmed
- Each submitted artifact traced to a controlled version in the configuration index
- Revision histories checked so no superseded document remains in the package
- Release records for software and hardware reconciled to the versions the evidence references
- Version-to-model applicability confirmed where models share or differ in evidence
- Mismatched items 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
- Every artifact in the package references a version present in the configuration index
- No superseded revision of a controlled document remains in the submission
- Release records match the software and hardware versions the evidence cites
- Evidence shared across models states which version applies to which aircraft
- The baseline the package claims is internally consistent across its artifacts
Evidence normally required
- The configuration index and baseline definition for the expansion
- Revision histories for the plans, reports, and data in the package
- Software and hardware release records and version identifiers
- The submission package as assembled for the added models
- The applicability matrix mapping versions to aircraft models
Common discrepancies
- A superseded revision of a report left in the package alongside its replacement
- An artifact referencing a software version that the release records do not show as released
- Shared evidence that does not state which added model each version applies to
- A configuration index that omits an artifact the package actually relies on
What is at stake
A submitted artifact that does not match the controlled configuration undercuts the whole evidence set, because a reviewer can no longer trust that any given report describes the version being approved. One superseded document in the package invites a version check across everything, which is slow and erodes confidence. Left unaddressed, the expansion carries an approval tied to a configuration the records cannot actually reconstruct.
How the work runs
Fix the baseline
Identify the configuration baseline the expansion claims and confirm what it covers.
Trace each artifact
Match every item in the package to a controlled version in the configuration index.
Reconcile releases and applicability
Check release records and version-to-model applicability for the added effectivity.
Align the mismatches
Sequence the out-of-baseline items into a closure plan before submission.
What the buyer receives
- A gap assessment of artifacts that do not match the controlled configuration
- A configuration-to-evidence reconciliation across the submission package
- A closure plan for aligning the mismatched items before submission
Who uses the output
- STC holders confirming the package reconstructs to a single controlled baseline
- Certification leadership relying on version-consistent evidence across the submission
- Program managers resolving version mismatches before the package is opened
How the work fits into the transaction or program
Configuration management binds the rest of the package together. The compliance map, the traces, the qualification reports, and the lifecycle data are only trustworthy if each references a controlled version, so this review runs late, once the artifacts are assembled, and confirms the whole set reconciles to one baseline before submission.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both expect the submitted data to trace to a controlled configuration, but the form of the configuration index and the release evidence each prefers can differ. The review notes where the control record is thin so the package reconciles cleanly for either authority.
Regulatory limits
This work reconciles the package to its controlled configuration. It does not establish the configuration management system, approve a baseline, or make a compliance finding on the configuration.
What this review does not cover
- Building or operating the configuration management system
- Re-releasing software, hardware, or documents to a new baseline
- Any finding of compliance on the controlled configuration
Specific to this review
- A superseded document is the most common configuration defect, because the older copy survives in the package after a later baseline replaces it.
- Shared evidence across models fails when it does not state which version applies to which aircraft, so applicability is checked per model.
- One version mismatch invites a reviewer to version-check the whole package, which is why configuration is reconciled before submission rather than after a query.
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 does configuration management matter so much for an expansion specifically?
An expansion assembles evidence across a long program history and several aircraft models, which is exactly where superseded versions and applicability gaps creep in. If a reviewer cannot tie each artifact to a controlled version, the evidence set loses its footing. The review confirms the whole package reconciles to one baseline before it is submitted.
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.