STC configuration control
STC program configuration management data support
This review confirms that the configuration management evidence behind an STC actually controls the data the rest of the package rests on. A certification engineer runs it before submittal, once baselines, revisions, and release records exist. It reads the baseline definitions, the revision and change history, and the release records, then checks that every artifact the package cites is the controlled version. You get a gap assessment, a trace map from the released baseline to the submitted evidence, and a closure plan for the records that do not reconcile.
When this review is needed
- A data package spans several disciplines and the modifier needs each artifact confirmed as the controlled version before submittal.
- Late changes rippled through the baseline and the release records have to catch up before the package goes formal.
- A supplier and the modifier maintained separate baselines and the two have to be reconciled into one controlled configuration.
- An earlier revision was submitted informally and the program needs to confirm the formal package reflects the current baseline.
The problem
Configuration management is the discipline that keeps every other artifact honest, and it fails quietly. A verification result cited in the accomplishment summary points at a revision that has since moved, or a supplier's baseline and the modifier's baseline drift apart across a change cycle, and nothing flags it until an authority asks which version was actually assessed. By then the whole package is suspect, because if the configuration is not controlled, no citation in it can be trusted.
What gets reviewed
- Baseline definitions for the STC data package across the disciplines it spans
- Revision and change history against the released configuration
- Release records confirming the controlled version of each artifact
- Reconciliation of supplier and modifier baselines into one configuration
- Trace from cited evidence to the controlled revision it represents
- Change control records for modifications made during the program
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 the package cites resolves to a released, controlled revision
- The revision history has no unreleased change sitting in the submitted baseline
- The supplier and modifier baselines reconcile to a single controlled configuration
- Release records identify who released each artifact and at what revision
- Verification and analysis results reference the configuration they were actually taken against
Evidence normally required
- Baseline definitions and the configuration index for the package
- Revision, change, and problem-report history
- The release records behind each controlled artifact
- Any supplier configuration records where the package includes supplier data
- The change control procedure the program worked to
Common discrepancies
- A cited verification result that points at a revision no longer in the baseline
- Supplier and modifier baselines that diverged across a change cycle
- An unreleased change sitting inside the submitted configuration
- A release record that cannot identify the revision of an assessed artifact
What is at stake
If the submitted evidence cannot be tied to a controlled baseline, an authority cannot rely on any of it, and the finding is not narrow. A single revision mismatch can put every downstream artifact into question and force the program to re-establish which version each result was taken against. Reconstructing configuration control after submittal is slower and less credible than proving it before.
How the work runs
Establish the baseline
Confirm the released baseline and configuration index the submitted package should represent.
Reconcile the revisions
Check revision and change history for unreleased changes sitting in the baseline.
Tie evidence to versions
Confirm each cited result references the controlled revision it was taken against.
Close the mismatches
Plan the reconciliation of supplier and modifier baselines and any unresolved records.
What the buyer receives
- A gap assessment on the configuration control across the package
- A trace map from the released baseline to each submitted artifact
- A closure plan for the records and baselines that do not reconcile
Who uses the output
- Certification engineers confirming the package rests on a controlled baseline
- Managers of configuration reconciling supplier and modifier baselines
- Program managers who need the configuration settled before submittal
How the work fits into the transaction or program
Configuration control underpins every other STC artifact, so this review is what lets the software, hardware, and safety evidence be taken at face value. It confirms the baseline before the package goes formal, so the authority reads results tied to a version the program can name, rather than a moving target.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both expect controlled configuration behind a data package, and where an STC is validated across both, the review notes where the same baseline has to be presented to a second authority so the controlled version is unambiguous to each.
Regulatory limits
The review confirms the configuration evidence is complete and the submitted data traces to a controlled baseline. It does not release any artifact, approve the configuration, sign a compliance finding, or make an airworthiness determination.
What this review does not cover
- Releasing or re-releasing any artifact into the baseline
- Operating the modifier's configuration management system on its behalf
- Signing a configuration compliance finding or authorizing release of the STC
Specific to this review
- A configuration failure is silent: a cited result stays readable while pointing at a revision that has moved, so nothing surfaces until an authority asks which version was assessed.
- Supplier and modifier baselines drift most across a late change cycle, when both sides revise under deadline and neither reconciles the other's version.
- If the configuration is not controlled, every citation in the package is suspect, which is why a single revision mismatch can put the whole submittal into question.
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. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Why does configuration management get its own review instead of being part of each discipline?
Each discipline controls its own artifacts, but the package as a whole has to present one coherent baseline, and that is where drift hides. A discipline can pass its own review while citing a revision another team has since changed. Reading configuration across the whole package catches the mismatches no single discipline would see.
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.