Configuration management evidence
Configuration management data evidence review for equipment suppliers
This review examines a supplier's configuration management data to confirm the evidence being submitted describes the configuration actually under control. It reads baselines, revision histories, and release records to check that requirements, design, verification, and the certified article all reference the same, current baseline, and that nothing submitted was captured from a superseded revision. A configuration-literate engineer runs it before submittal, in a finding response, or after a change that moved a baseline. You receive a gap list of evidence out of step with the controlled configuration, an evidence map, and a closure sequence for engineering leadership.
When this review is needed
- Several baselines have been released and the data package pulls artifacts that may span more than one of them.
- A late change moved a baseline and it is unclear which downstream evidence still describes the current one.
- A finding asks the supplier to show that a submitted report matches the configuration index for the certified article.
- Software, hardware, and system artifacts were baselined by separate processes that need to reconcile at release.
The problem
Configuration management is invisible until it fails, and it fails quietly. Each artifact is correct against the baseline it was drawn from, but a package assembled over months can carry a requirements document from one baseline, a test report from another, and a configuration index that names a third. Nothing looks wrong in isolation. The mismatch only appears when someone lays the release records side by side.
What gets reviewed
- Read of the baseline structure and the revision history for each controlled artifact class
- Confirmation that requirements, design, verification, and the article reference the same baseline
- Check of release records so each submitted artifact was drawn from a controlled revision
- Reconciliation of the configuration index against the artifacts the package actually contains
- Review of how baseline moves after changes propagated to dependent evidence
- Identification of submitted evidence captured from a superseded revision
What gets validated
- Requirements, design, verification, and the certified article all reference one current baseline
- Every submitted artifact traces to a release record for a controlled revision
- The configuration index lists the exact revisions the package contains
- Baseline changes propagated to all dependent evidence, with none left on a prior revision
- Software and hardware configuration indexes reconcile with the system-level baseline
Evidence normally required
- The configuration management records, including baselines and the change log
- Release records or authorized release documentation for each artifact
- The configuration index for the software, hardware, and system as applicable
- The data package as assembled for submittal, with the revision of each artifact
- The change history showing when and why baselines moved
Common discrepancies
- A test report in the package drawn from a baseline the requirements later superseded
- A configuration index listing revisions that differ from the artifacts actually enclosed
- A late change that moved the system baseline without updating the hardware index
- Artifacts released informally, without a release record tying them to a controlled revision
What is at stake
A configuration mismatch undermines every other review at once, because a reviewer who finds one artifact from a stale baseline can no longer trust that any artifact describes the certified article. The package then has to be re-baselined, which can invalidate verification that was run against the wrong revision, and this happens at submittal when there is least room to reassemble.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Establish the current baseline
Confirm which baseline the certified article sits on and treat it as the reference every artifact must match.
Reconcile the package
Compare each submitted artifact's revision against release records and the configuration index.
Trace baseline moves
Follow every baseline change through to dependent evidence and record anything left on a prior revision.
Sequence the re-baselining
Order corrections by dependency so a fixed baseline does not disturb evidence already reconciled.
What the buyer receives
- A gap list of submitted evidence that does not match the controlled configuration
- An evidence map aligning each artifact to its baseline and release record
- A closure sequence ordering re-baselining by the dependencies each move disturbs
Who uses the output
- Engineering leadership judging how much of the package a baseline mismatch reopens
- Certification leads assuring the authority the package describes one coherent configuration
- Configuration managers reconciling indexes and reissuing release records
How the work fits into the transaction or program
Configuration management is the frame every other evidence review sits inside, because a compliance map, a trace, or a qualification report only means something if it describes the controlled configuration. This review confirms that frame is intact so the findings of the other reviews attach to the right baseline, and it links to the conformity records review that ties the physical article to that configuration.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both require the certified configuration to be identifiable and controlled, and both DO-178C and DO-254 carry their own configuration management objectives at the item level. This review checks that the item-level indexes reconcile with the system baseline, which is the seam where separately managed software and hardware most often fall out of step.
Regulatory limits
This review evaluates whether the submitted evidence matches the controlled configuration. It makes no airworthiness determination, approves no configuration, and does not certify the configuration management system itself. Those determinations rest with the authority and its delegates.
What this review does not cover
- Operating the supplier's configuration management system or reissuing baselines
- Assessing whether the configuration management process meets a standard's objectives in full
- Judging the technical content of the configured artifacts
Specific to this review
- Configuration mismatches are invisible artifact by artifact and only appear when release records are laid side by side, which is why they survive to submittal.
- A single stale artifact does outsized damage, because it makes a reviewer doubt that any other artifact describes the certified article.
- The system-to-item seam is the usual failure point: a system baseline can move while a separately managed software or hardware index stays put.
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
Every document in our package is internally correct. How can there still be a configuration problem?
Because correctness is relative to a baseline. Each artifact can be right against the revision it was drawn from while the package as a whole mixes revisions from different baselines. The problem only shows when the release records are compared, and that is exactly the comparison this review runs before a reviewer does.
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.