Configuration management evidence
Configuration management data evidence review for quality teams
This review checks that the data a package submits is the controlled, released configuration it claims to be, rather than a working copy that drifted from the baseline. A certification specialist reads the baselines, revisions, release records, and change history with your quality function, and finds where submitted evidence does not match what the configuration records say was controlled. It runs before submittal, during a finding response, or when a change reworks a baseline that other evidence already cites. You receive a gap list, a map from each submitted artifact to its controlled baseline, and a closure sequence for quality leadership.
When this review is needed
- A data package is heading to submittal and quality wants each artifact confirmed against the controlled baseline.
- A finding questions whether the submitted evidence is the released revision or an uncontrolled working copy.
- A late change reworked a baseline and quality needs to know which cited artifacts now point at the old one.
- The evidence was assembled from several tools and repositories and no one has reconciled it to one release index.
The problem
Configuration control is the discipline everyone assumes is in place until a package is assembled and the revisions do not line up. Evidence is generated against a working revision, the baseline moves, the release index is updated, but a report, a result, or a drawing in the package still carries the earlier revision because it was pulled before the change. Quality holds a package where the artifacts are individually correct and collectively out of step with the baseline they claim.
What gets reviewed
- The release index and controlled baseline established as the reference the submitted data is checked against
- Each submitted artifact's revision compared to the revision the configuration records identify as released
- Change history reconciled so every baseline move is reflected in the artifacts that depend on it
- Configuration status accounting checked so the recorded state matches the actual set of released items
- Artifacts cited by other evidence checked so cross-references point at the current baseline, not a prior one
What gets validated
- Each submitted artifact carries the revision the release index identifies as controlled
- The change history accounts for every revision between the cited baseline and the current one
- Configuration status accounting matches the actual inventory of released items, with none missing or extra
- Cross-references from other evidence point at the current released revision of each artifact
- No working or draft revision has entered the package in place of its released counterpart
Evidence normally required
- The configuration index or release records identifying the controlled baseline
- The submitted data package with the revision of each artifact
- The change history and change records affecting the baseline
- The configuration status accounting records
- The plans defining how configuration control is meant to operate for the program
Common discrepancies
- A report in the package at a revision the release index shows was superseded
- A cross-reference in another artifact pointing at a prior baseline of the item it cites
- A released item missing from the configuration status accounting inventory
- A working revision pulled into the package before its formal release
What is at stake
A package whose artifacts do not match the controlled baseline gives a reviewer a reason to question all of it. They find one report at a superseded revision and can no longer trust that the rest is current, so a submittal that looked assembled goes back for a full configuration reconciliation. A configuration mismatch discovered late is worse than an evidence gap, because it puts the integrity of the whole package in doubt rather than one claim.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the controlled baseline
Establish the release index and the current baseline as the single reference the package is measured against.
Check each artifact's revision
Compare every submitted artifact to the revision the release records identify as controlled.
Reconcile the change history
Confirm every baseline move is reflected in the artifacts and cross-references that depend on it.
Sequence the re-pulls
Order the corrections so the baseline is reconciled before dependent artifacts are re-cited against it.
What the buyer receives
- A gap list naming each artifact whose revision does not match the controlled baseline
- A baseline map tying each submitted artifact to the released revision it should carry
- A closure sequence ordering the corrections so baseline reconciliation precedes dependent re-citation
Who uses the output
- Quality leadership deciding whether the package is configuration-clean enough to submit
- Configuration and certification engineers who need to know which artifacts to re-pull at the released revision
- The team responding to a finding that must show the submitted data is the controlled baseline
How the work fits into the transaction or program
Configuration management is what lets every other piece of evidence be trusted as current, so a mismatch here casts doubt on data that is otherwise sound. This review runs before submittal, reconciling the package to its controlled baseline while a wrong revision is a quick re-pull rather than after a reviewer treats one superseded artifact as reason to question the whole submittal.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect the submitted data to correspond to a controlled configuration, and the configuration management objectives in the software and hardware standards apply the same way under each. The finding path differs: FAA delegated findings against a project plan on one side, EASA review items and means-of-compliance acceptance on the other. The review reads the baseline reconciliation against whichever finding path the program is filing under.
Regulatory limits
This review reads your own configuration records and submitted data and reports where they agree and where they diverge. It does not make an airworthiness determination, does not issue or accept a compliance finding, and does not replace the authority's or the delegate's review of the configuration data.
What this review does not cover
- Operating the configuration management system or performing releases
- Re-generating the artifacts that carry the wrong revision
- Rendering the compliance finding an authority or delegate reserves
Specific to this review
- A configuration mismatch is more damaging than a single missing artifact, because one superseded revision makes a reviewer doubt the currency of everything around it.
- The failure is almost always timing: an artifact pulled before a baseline moved is individually correct and collectively wrong.
- Cross-references between artifacts are a frequent blind spot, since a cited item can be re-released without the citing artifact being updated to match.
- Configuration status accounting that omits a released item hides the gap in plain sight, because the inventory reads complete while it is not.
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 configuration management system is under control. Why check the package against it?
A controlled system does not guarantee a controlled package. Artifacts get pulled into a submittal at the revision they had when they were gathered, and a baseline that moves afterward leaves those copies stale even though the system itself is fine. This review checks the assembled package against the current baseline, which is where the mismatch actually lives.
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.