Configuration management
Configuration management evidence review for qualification test teams
A configuration management evidence review checks that the baselines, revisions, and release records tie every piece of submitted evidence to a controlled configuration. It is run for a qualification test team before submittal, a finding response, or a change that disturbs the baseline. The reviewer confirms that the artifacts in the package reference the released revisions they claim and that nothing is credited to a configuration that has since been superseded. You receive a gap list of evidence that does not match the controlled baseline, a configuration map, and the order to reconcile them in.
When this review is needed
- The package is heading to the authority and no one has reconciled the evidence against the released baseline.
- A finding questioned whether a test result was produced against the current configuration.
- Several change orders landed late and the baseline moved after some evidence was already generated.
- Software and hardware revisions were updated and the compliance data has to catch up to them.
The problem
Configuration management is the quiet substrate under every other evidence type, and it fails silently. A baseline moves, a revision is released, and the evidence generated a week earlier still references the old identifier. Nothing throws an error. The test report is valid, the analysis is sound, but it was run against a configuration the program has already left behind. The defect only surfaces when someone lines the evidence up against the release records and finds the revision numbers do not agree.
What gets reviewed
- Baselines and their release records reconciled with the submitted evidence
- Revision identifiers on artifacts checked against the controlled configuration
- Change history reviewed for baselines that moved after evidence was produced
- Software and hardware part numbers on results matched to the released configuration
- Superseded artifacts confirmed removed from the package or clearly marked
- Configuration status accounting reconciled across the evidence set
What gets validated
- Each artifact references a released revision that appears in the configuration record
- No result is credited to a configuration the baseline has since superseded
- Baseline changes are reflected in the evidence generated after them
- Part numbers and revisions on test articles match the controlled configuration
- Superseded documents are removed from the package or plainly identified as such
Evidence normally required
- The configuration status accounting and release records
- The baseline history and the change orders against it
- The evidence artifacts and the revisions they reference
- Software and hardware part number and revision data
- The change record for baselines that moved during the program
Common discrepancies
- A test result produced against a revision the baseline has since superseded
- An artifact whose revision identifier is not in the configuration record
- A baseline change that never propagated to the evidence generated after it
- A superseded document left in the package alongside its replacement
What is at stake
Evidence credited to a superseded configuration is a finding that can invalidate the result, forcing a rerun against the current baseline. Because configuration moves the whole package at once, a single late change can strand results across several evidence types simultaneously. Discovering that during authority review means reworking evidence that was considered closed, on the least forgiving part of the schedule.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Pull the release records
Establish the controlled baseline and the revisions the configuration record says are current.
Match evidence to revisions
Check the revision each artifact references against the released configuration.
Chase the late changes
Find baselines that moved after evidence was produced and the results that never caught up.
Order the reconciliation
Rank the stranded evidence by the rework each mismatch would require.
What the buyer receives
- A gap list of evidence that does not match the controlled baseline
- A configuration map tying each artifact to a released revision
- A closure order ranking mismatches by the rework each would trigger
Who uses the output
- Test leadership deciding which results need to be rerun against the current baseline
- Certification leadership answering an authority on configuration control
- Engineering leads propagating a late baseline change through the evidence
How the work fits into the transaction or program
Configuration control underpins every other evidence review, because a trace, a verification result, or a lifecycle record only holds if it points to the released configuration. This review runs to confirm that substrate before the package ships, so a stranded result is caught before the authority pulls the revision numbers. Its findings often reopen the verification-trace pass, since a superseded result no longer closes its requirement.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
The FAA and EASA both expect configuration control over compliance data, and their expectations largely converge, but they can differ on how formally configuration status accounting must be presented in the submitted package. The review notes where the accounting acceptable to one authority would benefit from a fuller presentation for the other on a dual-validation program.
Regulatory limits
The review confirms that submitted evidence maps to the controlled configuration. It does not operate the configuration management system, approve a baseline, or determine compliance. Acceptance of the configuration argument rests with the authority.
What this review does not cover
- Running or administering the configuration management system
- Approving or freezing a baseline
- Any compliance determination on the configuration
Specific to this review
- Configuration failures are silent: an artifact referencing a superseded revision throws no error, so the mismatch only shows when evidence is lined up against release records.
- Because a baseline moves the whole package at once, one late change can strand results across several evidence types in a single step.
- A superseded document left beside its replacement is a common finding, because removal is easy to forget when a revision lands late.
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
Our CM system tracks every revision. Why reconcile the evidence separately?
The system tracks the configuration; it does not check which revision a given test report or analysis was actually run against. This review lines the delivered evidence up against the release records and finds results credited to a superseded revision, which the system alone will not surface.
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.