Configuration management evidence
Configuration management data evidence review for avionics suppliers
This review confirms that an avionics supplier's configuration management data actually controls what is being submitted. A certification specialist checks that baselines are defined, that revisions and release records reconcile, and that the artifacts in the data package are the released revisions the configuration records name rather than working copies. It runs before submittal, during a finding response, or when a change moves a baseline that the evidence has not caught up to. You receive a gap list, an evidence map linking each submitted artifact to its controlled revision, and a closure sequence.
When this review is needed
- A data package is being assembled from several tools and the released revisions have not been reconciled against the configuration index.
- A baseline moved late and the evidence set may still carry artifacts from the prior baseline.
- A finding asks the supplier to show that a submitted artifact is the controlled, released revision.
- Software, hardware, and system data were configured separately and the revisions across them have never been cross-checked.
The problem
Configuration control is invisible until it fails, and it fails at assembly time. Artifacts are produced in one tool, released in another, and copied into a submittal folder by hand, and each hop is a chance for a working revision to travel under a released label. The configuration index is supposed to be the authority on what is controlled, but it is often the last thing updated, so the package and the index drift apart in the final rush before a submittal.
What gets reviewed
- Baselines confirmed defined for requirements, design, code or hardware, and verification data
- Release records reconciled so each controlled item has a released revision and a release authority
- Submitted artifacts matched to the released revision the configuration index names
- Change history reviewed so revision increments correspond to real, recorded changes
- Cross-domain revisions checked so software, hardware, and system data reference consistent baselines
- The configuration index itself confirmed current against the actual state of the controlled items
What gets validated
- Every submitted artifact is the released revision named in the configuration index
- Each controlled item has a release record with an identifiable release authority and date
- Revision increments in the change history correspond to recorded, substantive changes
- Software, hardware, and system data reference mutually consistent baselines
- The configuration index reflects the current controlled state, not a state from before the last change
Evidence normally required
- The configuration management plan and the configuration index for the item
- Baseline definitions for requirements, design, implementation, and verification data
- Release records and change history for the controlled items
- The assembled data package as it will be submitted
- Change records for any baseline moved since the package was first assembled
Common discrepancies
- A submitted artifact that is a working revision carrying a released label
- A configuration index that names a revision the release records never actually released
- Software and hardware data referencing baselines that no longer agree after a late change
- Revision increments with no recorded change behind them, or changes with no revision increment
What is at stake
A submittal built on the wrong revisions is a finding that undermines confidence in the whole package, because it makes an authority question every other artifact too. Once a reviewer catches one artifact that does not match its configuration record, the burden shifts to the supplier to prove the rest do, and that proof takes far longer than reconciling the revisions would have before submittal.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Confirm the baselines
Verify that baselines are defined for each data domain and that the configuration index names them accurately.
Match artifacts to releases
Trace each submitted artifact to its release record and confirm it is the released revision, not a working copy.
Cross-check the domains
Reconcile software, hardware, and system revisions so they reference mutually consistent baselines after any late change.
Reconcile before re-issue
Sequence the fixes so the index and release records are corrected before the package is assembled again.
What the buyer receives
- A gap list naming each artifact, baseline, or index entry that does not reconcile
- An evidence map linking every submitted artifact to its controlled, released revision
- A closure sequence that reconciles the index and release records before the package is re-issued
Who uses the output
- Certification leadership deciding whether the package is under control and ready to submit
- Configuration management staff who need the specific reconciliations to perform
- The team responding to a finding that questions an artifact's revision or release status
How the work fits into the transaction or program
Configuration management is the discipline that lets every other piece of evidence be trusted, because it fixes which revision each artifact actually is. This review sits at the assembly stage, catching the revision drift that creeps in as data moves from tools to a submittal, so the package presents controlled items rather than convincing copies.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect submitted data to be under configuration control, and both can ask the supplier to demonstrate it for a specific artifact. The review reconciles the package against the configuration records the program maintains, so the supplier can answer that demand for any artifact rather than scrambling to prove control after a reviewer has already found a mismatch.
Regulatory limits
This review reports whether the submitted evidence reconciles with the supplier's configuration records. It does not accept the data, does not issue a compliance finding, and does not make an airworthiness determination. It also does not establish or run the supplier's configuration management system; it reads the records that system produced.
What this review does not cover
- Building or operating the configuration management system itself
- Re-releasing artifacts or correcting release records on the supplier's behalf
- Accepting the data or issuing a compliance finding
Specific to this review
- Configuration failures cluster at assembly, not authoring, because the risky moment is the hand copy from a release tool into a submittal folder where a label and a revision can part ways.
- The configuration index is trusted precisely because it is the record everyone assumes is right, which is why it is the last thing updated and the first thing that drifts.
- Cross-domain consistency is the quiet gap: software and hardware baselines can each be internally sound yet reference a system baseline that a late change moved.
- A revision increment with no change behind it is as much a control failure as a change with no increment, and both point to a process that stopped tracking reality.
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 data is spread across several tools. Can you still reconcile it?
Yes, and multi-tool packages are where this review earns its keep. The reconciliation works from the configuration index outward, matching each submitted artifact to the release record regardless of which tool produced it, and it specifically checks the hand-off points between tools where a released label most often ends up on a working revision.
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.