Configuration management evidence
Configuration management evidence support for a major change
This review confirms that the configuration management evidence behind a major change describes the same controlled baseline the rest of the data package is built on. A certification engineer runs it once baselines, revisions, and release records exist but before submission. It checks that the submitted evidence names the configuration the change was actually verified against, that revisions are controlled through release, and that hardware and software items are identified to the level DO-254 and DO-178C expect. You receive a gap assessment, an evidence map keyed to the controlled configuration, and a closure plan for the mismatches that would otherwise surface mid-review.
When this review is needed
- The data package cites a baseline but no one has confirmed the verified evidence matches that exact revision.
- Software or complex hardware went through several drops and the release records do not clearly mark which one was tested.
- A change was made after a configuration was frozen and the evidence still points at the earlier state.
- A reviewer needs to know which controlled item each result belongs to and the identification is ambiguous.
The problem
Configuration control slips fastest where several disciplines move at different speeds. Software rolls a new build to fix a defect, hardware freezes a part number, and the compliance evidence is written against whichever revision was current when the author sat down. By submission the package can credit a test run on one build while the released configuration is another, and nothing in the paperwork makes the mismatch obvious until a reviewer asks which configuration was actually verified.
What gets reviewed
- The configuration baseline named in the data package confirmed against the released state
- Revision and change history traced through release records rather than working copies
- Hardware and software items identified to the level DO-254 and DO-178C require
- Verification evidence linked to the specific configuration it was produced against
- Post-freeze changes reflected in the evidence or flagged where they are not
- Configuration status mapped against the certification basis for the change
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- The baseline the package claims agrees with the release records for every controlled item
- Each verification result names the build or part number it was produced against
- Revisions are traceable through controlled release rather than an engineering working copy
- Software load and hardware part identification is unambiguous across the evidence set
- Changes made after a configuration freeze are reflected in the evidence or explicitly carried as open
Evidence normally required
- The configuration baseline and index for the change
- Release records and revision history for hardware and software items
- Verification results with the configuration each was run against
- The certification plan and the change impact assessment
- Part number and software load identification for the affected items
Common discrepancies
- A test result credited against a build that was later superseded before release
- A part number in the evidence that does not match the released configuration index
- A revision advanced in engineering but never captured in a controlled release record
- A post-freeze change with no corresponding update to the compliance evidence
What is at stake
Evidence that does not match the controlled configuration forces a reviewer to question every result that rests on it, because a passing test proves nothing if it was run on a superseded build. Reconstructing which revision each result belongs to after submission is slow, and in the worst case a verification activity has to be repeated against the released configuration, which is a schedule hit the program planned around avoiding.
How the work runs
Fix the baseline
Confirm the configuration the package claims matches the release records for every controlled item.
Trace each result
Tie each verification result to the specific build or part number it was produced against.
Check post-freeze changes
Confirm changes after a configuration freeze are reflected in the evidence or carried as open.
Plan the closure
Sequence the fixes so the evidence and the controlled configuration agree before review.
What the buyer receives
- A gap assessment listing each mismatch between evidence and the controlled configuration
- An evidence map keyed to the released baseline and its controlled items
- A closure plan for the configuration discrepancies before the package enters formal review
Who uses the output
- Certification engineers ensuring every result ties to the configuration it belongs to
- Configuration management leads reconciling release records with the compliance evidence
- Compliance managers tracking which configuration gaps still block submission
How the work fits into the transaction or program
The review runs after configuration items are baselined and before the compliance finding, confirming the package describes the state that was actually verified. Its evidence map underpins the conformity records and the compliance matrix, and its closure plan clears the configuration mismatches that would otherwise undermine every downstream result.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
The FAA and EASA both expect a change to be approved against an identified configuration, but the artifacts each authority asks to see and the way loadable software is called out can differ. The review notes where the configuration evidence needs to be expressed differently for each finding so one controlled baseline supports both.
Regulatory limits
The review confirms the configuration management evidence is consistent and traceable to the released state. It does not establish the configuration on the program's behalf, approve a configuration, or make any airworthiness determination.
What this review does not cover
- Building or operating the program's configuration management system
- Approving a configuration or release on the authority's behalf
- Re-running verification activities against the released configuration
Specific to this review
- Software builds move faster than any other item in a change, so the evidence most often credits a build that was current when written but superseded by release.
- A passing verification result carries no weight if it was run on a configuration the program never released, which is why identification is checked before the result itself.
- Post-freeze changes are the quiet failure mode: the design moves, the paperwork does not, and the two only diverge visibly when a reviewer asks which configuration was tested.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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).
Frequently asked questions
What if verification was run against a build we no longer release?
That is the discrepancy the review is built to catch. The result either has to be re-established against the released configuration or the difference between the tested and released states has to be assessed and justified. Finding it before submission is far cheaper than defending it during the finding.
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.