Pre-submittal review
Reconciling configuration baselines before a certification submittal
A configuration-baseline reconciliation lines up three things that are supposed to be identical and often are not: the configuration your evidence was generated against, the article that was actually built and tested, and the baseline named in the submittal. It runs before submittal, once analysis and test are done but the package is still being assembled, and it is done for the applicant's certification team. Where the three diverge, the pass ties the differences to conformity records, revision history, and evidence references, or flags them as gaps. You receive a closure brief, an evidence request list, and a disposition package aligned to one baseline a reviewer can hold the whole package against.
When this review is needed
- Test ran on an early build, the design changed after, and no one confirmed the evidence still describes the submitted part.
- Software or hardware revisions moved during the program and the baseline in the submittal may name a different one than the DO-178C or DO-254 evidence.
- Conformity records exist for the test article but were never reconciled against the configuration the package claims.
- A reviewer is expected to hold the whole package against one baseline and the team is not certain all parts agree.
The problem
Certification evidence is generated at a moment in a design's life, and the design keeps moving. An analysis is run against one revision, a test article is built to another, a late change is embodied to fix a problem, and the submittal names whatever the configuration record last captured. Each step is defensible on its own, but nobody stops to confirm the evidence, the article, and the submitted baseline still describe the same product. The mismatch is quiet until someone reads across all three.
What gets reviewed
- The configuration each analysis and test was generated against, extracted and recorded
- The as-built, as-tested configuration of the article reconstructed from conformity and build records
- The baseline named in the submittal compared against both evidence and article
- Software and hardware revision identity checked so DO-178C and DO-254 evidence maps to the submitted load
- Late changes and revisions traced to see whether evidence was regenerated or carried forward
- Every divergence tied to a conformity record and evidence reference or logged as an open gap
What gets validated
- The revision each report was run against is stated and matches the configuration the report is cited to support
- Conformity records place the test article at the configuration the evidence assumes
- The submitted baseline names the same part, software, and hardware revisions the evidence covers
- DO-178C and DO-254 baselines resolve to the exact software and hardware standard verified, not an adjacent build
- Post-test changes are shown to have regenerated evidence or are flagged where evidence was carried forward without basis
Evidence normally required
- The configuration management data and baseline definition for the product
- Conformity records and build documentation for the test article
- Analysis and test reports with the configuration each was generated against
- Software and hardware revision records tied to the DO-178C and DO-254 evidence
- The change history covering revisions embodied after evidence was generated
Common discrepancies
- Test evidence generated against a revision the design moved past before the article was built
- A submitted baseline that names a software load the DO-178C verification evidence does not cover
- Late changes embodied to fix a problem with no confirmation the affected evidence was regenerated
- Conformity records that place the article at a configuration different from the one the submittal claims
What is at stake
A reviewer who notices the tested revision differs from the submitted one has to question whether any of the evidence applies, and that doubt spreads across the package. In software and hardware, a baseline that names the wrong DO-178C or DO-254 revision can invalidate an entire body of verification evidence. Left to the authority to catch, a configuration mismatch reopens the compliance argument at its foundation and forces work the program thought was finished.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Pin the three configurations
Record the revision the evidence was run against, the as-built article configuration, and the baseline named in the submittal.
Read across them
Compare all three and mark every point where the tested, built, and submitted configurations disagree, including software and hardware revisions.
Reconcile or flag
Tie each difference to a conformity record and evidence reference, or log it as an open gap with an owner and a path.
Align to one baseline
Deliver a disposition package and a reconciled view in which every evidence reference maps to the single submitted configuration.
What the buyer receives
- A closure brief mapping where evidence, article, and submitted baseline diverge
- An evidence request list naming the conformity or revision records needed to reconcile each mismatch
- A reviewer-ready disposition package aligned to a single, stated baseline
- A reconciled configuration view tying every evidence reference to the submitted configuration
Who uses the output
- Certification engineers who must show the evidence describes the product being certified
- Configuration management owners closing the gap between as-tested and as-submitted
- Program managers confirming the package rests on one baseline before it ships
How the work fits into the transaction or program
Configuration is the spine the rest of the package hangs on: compliance claims, findings, and ICA all assume a fixed baseline. This pass fixes that baseline and proves the evidence was generated against it before the authority uses it as the reference for everything else. A reconciled configuration lets the compliance matrix and the finding register be read against a product that actually exists.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
The FAA under Part 21 and EASA under 748/2012 both expect the certified configuration to be defined and the evidence to trace to it. For software and hardware, DO-178C and DO-254 baselines are the anchor both authorities read verification against, so a revision mismatch there is treated as a foundational defect rather than a paperwork slip. The reconciliation reads to whichever basis the program agreed.
Regulatory limits
This work reconciles configuration descriptions across evidence, article, and submittal and identifies where they diverge. It does not perform conformity inspection, approve a configuration, make compliance findings, or determine airworthiness. Conformity and approval remain with the authority and its delegates.
What this review does not cover
- Performing conformity inspection of the test article or production part
- Regenerating analysis or test evidence for a changed configuration
- Approving a baseline or making compliance findings on the authority's behalf
Specific to this review
- A configuration mismatch is the most expensive pre-submittal defect, because it does not weaken one claim, it puts a question mark over every piece of evidence tied to the wrong baseline.
- In DO-178C and DO-254 work, naming the wrong software or hardware revision in the baseline can strand an entire verification effort, since the evidence proves a build the submittal does not claim.
- A late change embodied to fix a test failure is the classic trap: the fix is defensible, but the evidence for everything the fix touched may never have been regenerated.
- Conformity records and the submitted baseline are written by different people at different times, so they drift apart silently until someone reads them side by side.
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 a small revision difference matter if the change was minor?
Because the authority does not know it was minor until you show why. A baseline that names a different revision than the evidence covers forces the reviewer to ask whether the evidence still applies, and answering that means tracing what the change touched. In DO-178C and DO-254 work even a minor revision can move the software or hardware standard the verification proved, so the question is rarely as small as the change felt.
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.