Configuration control
Configuration management evidence review for software assurance teams
This review confirms that the configuration your certification data claims is the configuration the records actually control. A certification engineer reads the baselines, revision history, release records, and change log across your DO-178C, DO-254, and ARP4754B evidence, then checks that every submitted artifact ties back to a controlled item at the revision the data package cites. Assurance teams run it before submittal, in a finding response, or after a change that touched several artifacts at once. You receive a gap list, an evidence map, and a closure sequence.
When this review is needed
- A submittal pulls artifacts from several tools and baselines and you need to know they all describe the same build.
- The authority asked which revision of an artifact a compliance claim actually rests on.
- A late change rippled across code, tests, and design data and the baselines have to be reconciled.
- Two teams contributed to the package and their revision numbering never fully aligned.
The problem
Configuration management is the connective tissue of a data package, and it fails silently. An artifact carries a revision, a baseline names it, and a release record blesses it, but those three can drift apart across a long program without any single edit looking wrong. A verification result run against build seven and a summary written for build eight both look complete, and the mismatch only shows when someone pulls the thread on which revision a claim is really about.
What gets reviewed
- Baselines and their contents at each controlled point in the lifecycle
- Revision identification on every artifact the submittal references
- Release records and the authority behind each release
- Change history and problem-report links across affected artifacts
- The configuration index and its agreement with the artifacts it lists
- Consistency of configuration data across the software, hardware, and system evidence
What gets validated
- Each artifact the submittal cites carries a revision that a baseline actually controls
- The configuration index lists the revisions the compliance claims depend on
- Verification results were run against the build the summary describes, not an earlier one
- Release records exist for every configuration item the package presents as approved
- Revision numbering reconciles across teams and tools with no colliding or orphaned identifiers
Evidence normally required
- The configuration index for the submittal
- Baseline definitions at each lifecycle transition
- Release records and change history
- Problem reports with their configuration links
- The artifact set the compliance claims reference
Common discrepancies
- A compliance claim that cites an artifact revision no baseline controls
- Verification results run against an earlier build than the summary presents
- A configuration index that lists a revision the artifact set does not contain
- Colliding revision identifiers where two teams merged their work
What is at stake
If the evidence does not tie to a controlled configuration, the authority cannot rely on any compliance claim built on it, and a single unresolved baseline question can put the whole package in doubt. Reconstructing which artifact belongs to which build after the fact is slow, and in the worst case forces re-verification simply to prove what was tested against what.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the index
Take the configuration index as the claim and check every artifact it lists actually exists at that revision.
Tie claims to revisions
Follow each compliance claim to the controlled revision it depends on and confirm the two agree.
Check the release trail
Verify release records exist for the items presented as approved and that change history is linked.
Reconcile and sequence
List the mismatches and order the baseline reconciliation so submittal rests on one build.
What the buyer receives
- A gap list of artifacts that do not tie to a controlled configuration
- An evidence map linking each compliance claim to the controlled revision behind it
- A closure sequence for reconciling baselines and release records before submittal
Who uses the output
- Assurance leads confirming the whole package describes one coherent build
- Certification leadership answering an authority question on artifact revision
- Configuration and engineering leads reconciling baselines after a cross-cutting change
How the work fits into the transaction or program
Configuration management underpins every other evidence type, since a compliance claim is only as good as the revision it points to. Checking it before submittal means the software, hardware, and safety packages all rest on the same controlled build, so a reviewer cannot pull one thread and unravel the rest.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect configuration control over certification data, and both hold the applicant to the configuration index the data package presents. Where the two diverge is in the liaison and data submission expectations at each stage, so the review notes where an index adequate for one authority would need supplementing for the other.
Regulatory limits
This review reads configuration records for consistency. It does not establish a baseline, issue a release, or make a compliance finding. Configuration control and its acceptance remain with the applicant and the authority.
What this review does not cover
- Establishing or correcting baselines in your configuration tool
- Issuing release records or approving configuration items
- Any compliance finding on the configuration data
Specific to this review
- Configuration mismatches are the quietest defect in a data package, because every artifact can look individually correct while pointing at different builds.
- A verification result and an accomplishment summary written for different builds is the single most common cause of a baseline finding.
- Merging two teams' work is where revision identifiers collide, so cross-team programs carry more configuration risk than single-team ones.
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
We use several tools across teams. Does that break the review?
No, it is exactly where the review earns its keep. Multiple tools and teams are where revision identifiers drift and collide. We work from the configuration index and reconcile the artifacts back to it regardless of which tool produced each one.
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.