Configuration management evidence review for certification teams

When this review is needed

• A data package is heading to the authority and the team needs to know every artifact reflects the current baseline.
• A finding questions whether test results were run against the released configuration or an earlier build.
• A design change forced a re-baseline and the evidence has to catch up to the new configuration index.
• Software and hardware artifacts came from separate suppliers and the baselines have not been reconciled against each other.

The problem

Configuration control is easy to state and hard to hold across a real program. Requirements revise, source is rebuilt, drawings are redlined, and test reports capture whatever build existed the day the test ran. Each artifact carries its own version stamp, and the configuration index that is supposed to reconcile them lags the fastest-moving items. By submittal, a compliance argument can cite a report generated against a build two revisions behind the one the release record now calls current.

What gets reviewed

• Baselines identified for each artifact class and confirmed against the controlling configuration index
• Revision histories checked for a continuous, accounted-for chain with no unexplained jumps
• Release records reconciled to the versions the compliance evidence actually cites
• Change history mapped so that each approved change is reflected in the affected artifacts
• Software and hardware baselines cross-checked at their integration boundary for version agreement
• Configuration references in the certification data confirmed against the agreed certification basis

What gets validated

• Each submitted artifact names a version that the configuration index lists as controlled and current
• Revision chains reconcile without a gap where a version appears from nowhere or vanishes silently
• Release records match the specific builds cited by the analyses and test reports that rely on them
• Every approved change order is traceable into the artifacts it was supposed to modify
• Hardware and software baselines agree at the interface where their evidence is combined

Evidence normally required

• The configuration index or equivalent record identifying controlled baselines
• Release records for the software, hardware, and system artifacts in the package
• Change history and approved change orders affecting the baseline
• The compliance evidence set whose configuration references need checking
• The agreed certification basis and any prior findings touching configuration control

Common discrepancies

• A test report cited as compliance evidence that was generated against a superseded build
• An approved change order that was never reflected in one of the artifacts it should have modified
• A revision chain with an unexplained gap where an intermediate version is undocumented
• Hardware and software baselines that disagree at the integration boundary they share

What is at stake

Evidence that describes an uncontrolled configuration is not evidence at all, and an authority that spots the mismatch can invalidate the affected findings. The team then re-runs analyses or tests against the correct baseline under a compressed schedule, and every downstream claim that leaned on the discredited artifact has to be re-examined for the same defect.

How the work runs

What the buyer receives

• A gap list naming each artifact whose configuration does not reconcile and why
• An evidence map tying every artifact to its controlled baseline and release record
• A closure sequence ordered so re-baselined artifacts are corrected before dependent evidence is re-cited

Who uses the output

• Compliance management confirming the package cites only controlled configurations before it is submitted
• Configuration and engineering leads correcting the artifacts flagged as out of baseline
• Certification leadership judging whether the evidence set is submission-ready or needs a re-baseline pass

How the work fits into the transaction or program

The review runs across the evidence set once the artifacts exist but before the compliance argument depends on them. It confirms the package describes one coherent, controlled configuration, and its gap list feeds the re-baselining and re-runs that have to finish before any affected finding can stand.

Jurisdiction-specific considerations

FAA and EASA both expect configuration management consistent with ARP4754B and the software and hardware guidance in DO-178C and DO-254, but the way each authority wants configuration status accounting demonstrated in the data package differs, so the review notes where a baseline record that satisfies one authority needs additional status accounting to satisfy the other.

Regulatory limits

The review checks that the evidence reconciles to a controlled configuration. It does not approve the configuration management plan, accept the baseline, or make a compliance finding on the data. Acceptance of the configuration and any finding remain with the applicant's authorized representatives and the authority.

What this review does not cover

• Operating or correcting the applicant's configuration management system
• Re-running the analyses or tests that were performed against the wrong build
• Approving a baseline or making any compliance finding on the data package

Specific to this review

• Test reports are the artifacts most likely to fall out of baseline, because they freeze whatever build existed on test day while requirements and source keep moving.
• The integration boundary between separately supplied hardware and software is where baseline disagreement hides, since neither supplier owns the other side's version.
• A missing intermediate revision is rarely benign: it usually means a change was made and released without passing through the controlled chain.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits