Configuration evidence
Configuration-management evidence review for avionics and equipment suppliers
A configuration-management evidence review checks whether a supplier's configuration records pin the certification data to one identifiable build. It is for avionics and equipment teams whose configuration index, baselines, and change history have to agree before the package is submitted. The review covers the configuration management plan, the item identification scheme, the baseline set, and the change-control records. You receive a reconciled configuration index and a list of items whose baseline, revision, or change history does not match the evidence that cites them.
When this review is needed
- The certification data is heading for submittal and the configuration index has to be confirmed against the artifacts it lists.
- A late design change moved a baseline and no one has reconciled the affected items against their evidence.
- Two record systems hold configuration data that no longer agree on which revision is current.
- A reviewer cannot tell which build a given test report or lifecycle artifact was run against.
The problem
Configuration data is the spine the rest of the package hangs on, yet it is the first thing to drift. Items get re-identified, baselines move with each change, and the index keeps listing a revision the evidence no longer matches. When the configuration index and the artifacts disagree, a reviewer can no longer say the data describes the article that was actually built, and the questions start at the baseline rather than the engineering.
What gets reviewed
- The configuration management plan and the identification scheme it defines for items
- The configuration index and whether each entry names a real, current artifact revision
- The baseline set and the point in the program each baseline was meant to capture
- Change-control records and the trail from a change request to the affected items
- Whether conformity records pin the data to a single identifiable build
- Agreement between configuration data held in more than one record system
What gets validated
- Each configuration item carries a unique identifier under the scheme the plan defines
- Every index entry points to an artifact revision that exists and is current
- Each baseline names the artifact revisions it freezes and the program point it captures
- Every change request traces to the items it touched and the revision it produced
- The conformity records identify the single build the certification data describes
- Where configuration data lives in separate systems, the systems agree on the current revision
- Superseded revisions are marked so an obsolete artifact cannot be cited as evidence
Evidence normally required
- The configuration management plan and the item identification scheme
- The current configuration index or item list
- The baseline records and the change-control log
- The conformity records for the build the data is meant to describe
- An index to the cited artifacts or access to the artifacts themselves
Common discrepancies
- An index that lists a revision the underlying artifact has since superseded
- Baselines that name items but not the specific revisions they were meant to freeze
- Change requests that close without a trace to the items they were supposed to update
- Two record systems disagreeing on which revision of an item is current
- Conformity records that do not resolve to one identifiable build
- Items missing a unique identifier under the plan's own scheme
What is at stake
A package whose configuration records do not converge forces the reviewer to reconstruct the build before reading the evidence. That turns one review into several, and every change made while the question is open adds another revision to reconcile.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Read the plan
Confirm the configuration management plan and the item identification scheme it commits the program to.
Reconcile the index
Check each configuration item against its current artifact revision and flag entries that point at superseded data.
Trace the baselines
Tie each baseline to the revisions it freezes and follow change requests through to the items they touched.
Resolve to a build
Confirm conformity records identify one build and deliver a prioritized list of the inconsistencies to close.
What the buyer receives
- A reconciled configuration index with each entry confirmed or flagged
- A list of items whose baseline, revision, or change history is inconsistent
- A baseline-to-build trace showing what each baseline freezes
- A prioritized closure list ordered by how far an item has drifted from its evidence
Who uses the output
- Configuration management leads reconciling the index before submittal
- Quality assurance leads confirming the change trail is intact
- Certification leads confirming the data describes one build
- Engineering teams closing the flagged baseline and change-trace gaps
How the work fits into the transaction or program
The review is a focused check on the configuration layer that the qualification, software, and hardware evidence all reference. It pairs with a compliance-matrix review when the entries above the configuration data also need confirming, and with a quality-assurance records review when the question is whether the process was followed.
Start with a single asset
Confirm requirements trace through verification.
Aircraft-specific considerations
Configuration depth tracks the article and its design assurance level, not the airframe it installs on. A complex programmable item under a higher assurance level carries more baselines and tighter change control than a simple part, so the reconciliation effort scales with the item's complexity and the rigor its function demands.
Jurisdiction-specific considerations
FAA and EASA both expect configuration data to identify the certified build, but the framing differs. FAA work references the configuration commitments in the lifecycle plans, while EASA Part-21 ties configuration control to the design organization's procedures. The artifacts overlap, so the review checks the records against whichever framework the program is submitting under rather than assuming one stands in for the other.
Regulatory limits
Endeavor Elements checks the applicant's configuration records for completeness, consistency, and traceability. It does not make compliance findings, issue any approval, or certify that a configuration is airworthy. The applicant and the authority keep their roles.
What this review does not cover
- Issuing any approval or making official compliance findings
- Building or maintaining the supplier's configuration management system
- Re-baselining the program or generating the missing change records
Specific to this review
- Drift in the configuration data is usually the root cause behind evidence findings: the artifact is fine, but the index points at a revision it has outgrown.
- A baseline that names items without their specific revisions cannot freeze a build, so the certification data has nothing fixed to describe.
- When two record systems hold configuration data, the disagreement between them is more common than an error inside either one.
- Conformity is only meaningful against a single resolved build; an unresolved configuration leaves conformity claims pointing at nothing definite.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
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).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Is this the same as a compliance-matrix review?
No. A compliance-matrix review checks that requirements map to evidence. This review checks the configuration layer underneath, confirming that the cited evidence describes one identifiable build before the matrix relies on it.
Do you fix our configuration management system?
No. The review reports where baselines, revisions, and change history are inconsistent and orders the gaps by review risk. The supplier keeps ownership of its configuration system and closes the items.
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.
Walk through your situation with an engineer who has done this work.