Configuration management
Configuration management evidence review for hardware assurance teams
A configuration management evidence review confirms that the baselines, revisions, and release records identify the exact configuration each piece of certification evidence was produced against. It is run by a hardware assurance team before submittal, a finding response, or a design-change assessment. The review checks that the submitted evidence names a controlled configuration, that change history is complete, and that no evidence cites a build the configuration records do not contain. You receive a gap list, an evidence map linking evidence to its controlled configuration, and a closure sequence for the assurance lead.
When this review is needed
- A data package is heading to submittal and each piece of evidence has to name a controlled configuration.
- Several revisions ran in parallel and the team needs to confirm the evidence set is internally consistent.
- An authority finding questioned which build a specific test or analysis result was produced against.
- A design change created a new baseline and the evidence has to be reconciled to it.
The problem
Configuration control is where a package that looks complete comes apart under scrutiny. Test results reference a build number that predates the released baseline, a plan cites a revision the configuration index never captured, and parallel work streams leave two documents describing the same item differently. The individual documents can all be valid while the set as a whole no longer points to one controlled configuration.
What gets reviewed
- Each evidence item checked for a reference to a controlled configuration identifier
- Baselines and revisions reconciled across the plans, design data, and verification records
- Change history checked for completeness against the released configuration
- Parallel work streams checked for conflicting descriptions of the same item
- Release records confirmed to cover the configuration the evidence was produced against
- The configuration index checked against the items the submittal actually references
What gets validated
- Every submitted evidence item names a configuration the release records actually contain
- Baselines and revisions are consistent across plans, design data, and verification records
- The change history accounts for every revision between the tested and released builds
- No two documents describe the same configuration item in conflicting terms
- The configuration index lists each item the submittal references
Evidence normally required
- The configuration management records and the configuration index
- Baseline and revision history for the plans, design data, and verification records
- Release records for the configuration being certified
- The evidence set proposed for submittal with its configuration references
- Change records for revisions produced during the program
Common discrepancies
- A test result referencing a build that predates the released baseline
- A configuration item described two ways across parallel work streams
- A change in the history with no corresponding release record
- A submitted document citing a revision the configuration index never captured
What is at stake
Evidence that cannot be tied to a controlled configuration cannot be relied on, and an authority that finds the mismatch can reject the affected results outright. Reconstructing which build each result came from after the fact is slow and sometimes impossible, so a configuration break can force a retest the program did not budget for.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Fix the released baseline
Establish the controlled configuration the submittal is meant to certify against.
Trace evidence to build
Confirm each evidence item names a configuration the release records contain.
Reconcile the streams
Check parallel revisions and change history for conflicts and unrecorded builds.
List the breaks
Flag evidence that does not tie to a controlled configuration and sequence the fixes.
What the buyer receives
- A gap list of evidence items that do not tie to a controlled configuration
- An evidence map linking each item to the configuration it was produced against
- A closure sequence ordering the reconciliations by dependency and effort
Who uses the output
- Assurance leads confirming the evidence set points to one controlled configuration
- Certification leads answering a finding on which build a result came from
- Engineering owners reconciling evidence to a new baseline after a change
How the work fits into the transaction or program
The review is the check that binds the rest of the evidence together, confirming that verification, safety, and qualification data all reference the same controlled configuration before submittal. Its gap list drives the reconciliations that have to close, and its evidence map is the reference an authority uses to confirm which build the package rests on.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect certification evidence to be tied to a controlled configuration, and each can present its configuration expectations through its own guidance. The review notes where a configuration record satisfies one authority's expectation and where the other would ask for the identification to be shown more explicitly in the submittal.
Regulatory limits
The review checks that evidence identifies a controlled configuration. It does not approve the configuration management process, release a configuration, or make a compliance determination for the authority.
What this review does not cover
- Operating or approving the configuration management system itself
- Releasing or baselining any configuration
- Determining compliance of the configured product
Specific to this review
- Configuration is the check that fails a package as a whole rather than one document, because a single build mismatch can invalidate every result produced against it.
- Parallel revision streams are the usual source of conflicting item descriptions, since two branches can each be internally valid while disagreeing with each other.
- The window to recover which build a result came from closes fast, so a configuration break found late often forces retest rather than reconciliation.
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
Why does one build mismatch matter if the test itself was valid?
A valid test against the wrong build still cannot support the certified configuration. If the result cannot be tied to the released baseline, an authority cannot rely on it, and recovering the link after the fact is often harder than rerunning the test.
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.