Configuration management evidence
Configuration management evidence review for aircraft modifiers
A configuration management evidence review confirms that the submitted certification evidence matches the controlled baseline it claims, through the baselines, revisions, release records, and change history that define it. It is run for aircraft modifiers before a submittal, in a finding response on configuration control, or when a change wave has churned the baseline. The review targets evidence that describes one revision while the controlled configuration is another, and change history with missing or out-of-order steps. You get a gap list of configuration mismatches, an evidence map to the controlled baseline, and a closure order.
When this review is needed
- A submittal must show that every piece of evidence reflects the configuration actually being certified.
- A finding questioned whether the baseline was under control across the evidence set.
- A late change wave revised drawings, software, and hardware and the evidence may lag the new baseline.
- Evidence was drawn from multiple disciplines and tools whose revision states were never reconciled to one baseline.
The problem
Configuration management is the quiet discipline that makes every other piece of evidence trustworthy, and it is the one that erodes fastest under change pressure. A drawing is revised but the analysis still cites the old sheet; software rolls to a new build while the verification report references the prior one; a release record is skipped in the rush. Each artifact looks correct in isolation, but together they describe several different configurations, and the certification claim rests on the assumption that they describe one.
What gets reviewed
- Baselines identified so the configuration each evidence artifact should reflect is unambiguous
- Revision states across drawings, software, and hardware reconciled to a single controlled baseline
- Release records checked for completeness and correct sequence through the change history
- Cited references in evidence checked against the controlled revision they claim
- Change history checked for gaps, out-of-order steps, or unrecorded changes
- Cross-discipline artifacts confirmed to describe the same configuration at submittal
What gets validated
- Each evidence artifact names the baseline revision it applies to
- Drawing, software, and hardware revisions reconcile to one controlled baseline
- Release records exist and are in order for every change in the history
- A reference cited in evidence resolves to the controlled revision it claims
- No change appears in the artifacts without a corresponding release record
Evidence normally required
- The configuration management records: baselines, revision logs, and release records
- The change history for the modification
- The evidence set whose references must resolve to the baseline
- The controlled document register across disciplines
- Any late change notices issued near submittal
Common discrepancies
- An analysis citing a drawing revision that a later change already superseded
- A verification report referencing a software build earlier than the controlled one
- A change present in the artifacts with no release record behind it
- Cross-discipline evidence describing two different configurations at submittal
What is at stake
When evidence does not agree on the configuration, an authority cannot know which build the certification claim actually covers, and that ambiguity can put the entire package in question rather than a single row. Reconciling it late is painful, because chasing a baseline mismatch means re-checking every artifact that cited the superseded revision, often across disciplines that maintain their records separately.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the baselines
Identify the controlled baseline each evidence artifact should reflect so mismatch can be measured against it.
Reconcile revisions
Check drawing, software, and hardware revision states and the references in evidence against that baseline.
Audit the change history
Walk the release records for gaps, out-of-order steps, and changes present in artifacts but absent from the log.
Deliver mismatches
Return the configuration mismatches with an evidence map and a closure order led by the widest-reaching ones.
What the buyer receives
- A gap list of configuration mismatches by artifact and the revision each should reflect
- An evidence map tying each artifact to the controlled baseline revision
- A closure order that reconciles the widest-reaching baseline mismatches first
Who uses the output
- STC program managers confirming the package describes one configuration
- Certification engineers answering a finding on configuration control
- Engineering leads coordinating the cross-discipline reconciliation the gaps expose
How the work fits into the transaction or program
Configuration control is the assumption every other evidence review quietly depends on, because a trace, a verification result, or a qualification report only means what it says if it describes the certified baseline. Reconciling the evidence to one controlled configuration before submittal keeps the whole data package pointing at the same aircraft.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both require configuration control over certification data, and both expect status accounting that can show what revision each artifact reflects. The review checks the records against the governing authority's expectation for baseline traceability rather than treating a revision log as sufficient on its own.
Regulatory limits
This review checks the modifier's configuration management records against the evidence set. It does not establish the baseline, does not make a compliance finding, and does not determine airworthiness. Configuration acceptance for approval remains with the authority.
What this review does not cover
- Establishing or re-baselining the configuration for the modifier
- Reissuing release records or revising the artifacts
- Reconciling supplier configuration records on the modifier's behalf
Specific to this review
- Configuration integrity degrades fastest exactly when the program is busiest, because late change waves outrun the release process that is supposed to record them.
- Every artifact can be individually correct and the package still be wrong, since correctness in isolation says nothing about agreement on one baseline.
- Cross-discipline mismatches are the hardest to catch, because drawings, software, and hardware are usually controlled in separate systems reconciled only at submittal.
- A single missing release record breaks status accounting for every artifact that depends on that change, well beyond the one artifact it belonged to.
Sources
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).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
Each of our documents is at its correct revision. Why review configuration?
Individual correctness is not agreement. The review checks that every artifact reflects one controlled baseline, so an analysis on an old drawing revision or a report on a prior software build does not leave the package describing two configurations at once.
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.