Configuration management
Configuration management evidence support for installation approval
Configuration management support checks that the evidence a modifier submits matches the controlled configuration it claims to describe. It is prepared by or for the modifier before an installation approval package enters formal review. The work reads the baselines, the revision history, the release records, and the change history, then tests whether each submitted artifact sits at the revision the controlled build actually holds. You receive a configuration reconciliation view, a gap assessment where submitted evidence has detached from the controlled baseline, and a closure plan to bring the package back onto one configuration before submittal.
When this review is needed
- A package pulls evidence from software, hardware, test, and design activities that each keep their own revision scheme, and no one has reconciled them to a single build.
- A late design change moved a baseline and the project needs to confirm every affected artifact was reissued rather than left at the prior revision.
- Release records were produced by separate teams and the modifier has to show they describe the same controlled configuration.
- A reviewer is expected to check that the evidence describes one aircraft, and the team wants revision drift found before that check.
The problem
Every evidence stream in an installation package carries its own configuration, and the package is only coherent if they all point at the same build. In practice a change ripples through some artifacts faster than others. A wiring drawing gets reissued while the analysis that referenced it does not, or a software load advances while the test report cites the prior one. Each artifact is internally valid, so nothing looks wrong until someone lines them up and finds two revisions of the same aircraft in one package.
What gets reviewed
- The configuration baselines the package claims, listed against the artifacts that should sit on each
- Revision history checked so a change propagated to every affected artifact
- Release records confirmed to describe the same controlled build the evidence references
- Change history reconciled so no superseded revision remains in the submitted set
- Cross-stream consistency checked so software, hardware, test, and design point at one configuration
- A closure plan to reissue or re-cite the artifacts that lagged a change
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 submitted artifact sits at the revision the controlled baseline records for it
- A design change propagated to each downstream artifact that referenced the changed item
- Release records identify the same configuration the evidence describes, with no split
- No superseded revision of any artifact remains in the submitted package
- The software load, hardware standard, and drawing set all describe one build
Evidence normally required
- The configuration baselines and the configuration index for the package
- Revision and release records for each evidence stream
- The change history and any change impact assessments
- The design data, test reports, and lifecycle data as submitted
- The controlled configuration the installation is approved against
Common discrepancies
- A drawing reissued after a change while the analysis citing it stayed at the prior revision
- A test report referencing a software load superseded by the one now installed
- A release record describing a configuration that differs from the evidence set it accompanies
- A superseded artifact left in the package alongside its replacement
What is at stake
Evidence that describes more than one configuration invites a reviewer to ask which one is being approved, and there is rarely a clean answer once the drift is in the package. Reconciling it late means chasing which artifacts moved and which lagged across every stream at once, under the deadline the submittal was supposed to meet. Worse, an approval granted against a mixed configuration leaves the modifier unable to say precisely what was approved.
How the work runs
Fix the target build
Establish the controlled configuration the package is meant to describe and treat it as the reference.
Place each artifact
Confirm every submitted artifact sits at the revision the baseline records for it.
Trace the changes
Follow each design change through the streams and find the artifacts that lagged it.
Plan the closure
Sequence the reissues and re-citations needed to bring the package onto one build.
What the buyer receives
- A configuration reconciliation view across the evidence streams
- A gap assessment naming each artifact that has drifted from the controlled baseline
- A closure plan to bring the package onto one configuration before submittal
Who uses the output
- Certification project managers confirming the package describes a single build
- Engineering leads identifying which artifacts a change left behind
- Compliance staff who will assert the configuration the evidence represents
How the work fits into the transaction or program
Configuration control is the connective tissue under every other evidence stream, so this reconciliation is run once the streams are assembled and again after any late change. It confirms the compliance matrix, the conformity records, and the lifecycle data all describe the same aircraft, which is the premise the whole package rests on.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both require that approved data describe a controlled configuration, and the reconciliation is agnostic to which authority receives it. Where the two differ is in the release form and identification conventions the records use, so the check confirms the configuration is coherent without assuming one authority's release format satisfies the other.
Regulatory limits
The work reconciles the submitted evidence to the controlled configuration and flags drift. It does not establish the configuration, does not issue release records, and does not make a compliance finding or grant an approval. Configuration control and the compliance determination rest with the applicant and the authority.
What this review does not cover
- Establishing or approving the configuration baseline itself
- Issuing release records or configuration control documents
- Any compliance finding or approval on the configuration
Specific to this review
- A change propagates through evidence streams at different speeds, so drift almost always appears at the artifact that referenced a changed item rather than at the item that changed.
- A package can be internally valid stream by stream and still describe two aircraft, which is why cross-stream reconciliation catches what per-stream review misses.
- An approval granted against a mixed configuration is the quiet failure mode: nothing stopped the submittal, but the modifier can no longer state exactly what was approved.
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.
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.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
Frequently asked questions
Each report is correct on its own. Why does cross-checking matter?
An installation package is approved as one configuration. If a change reached some artifacts and not others, each can be internally correct while the package as a whole describes two builds. The reconciliation lines the streams up so the evidence points at a single aircraft before a reviewer asks which one is being 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.