TSO finding closure
Closing evidence, test article, and submitted configuration that do not match
This is support for equipment suppliers whose certification evidence, test article, and submitted configuration do not describe the same thing. A specialist reconciles the three: the configuration the evidence was generated against, the configuration the test article actually was, and the configuration named in the submittal, tracing revisions and conformity records until they agree or the disagreement is explained. The work happens during the program, before a reviewer notices that a test report and the submitted part standard describe different builds. You receive a closure brief listing every configuration mismatch, an evidence request list for the conformity or revision records needed, and a disposition package that reconciles baseline, revisions, conformity, and evidence references.
When this review is needed
- A reviewer notices a test report describes a different build than the submitted part standard.
- The article was revised after qualification, and the evidence was never re-baselined to the shipped configuration.
- Conformity records for the test article do not match the configuration the evidence claims.
- Software and hardware revisions moved independently and the top-level configuration no longer bounds them.
The problem
Certification rests on the assumption that the evidence, the article it was generated on, and the configuration being submitted are one build, but those three are maintained by different processes that drift apart. A late design change lands after the test campaign, a programmable part gets a revision after conformity, a report keeps the old part number while the submittal quotes the new one. Each drift is small and defensible on its own, and together they leave a package where no single configuration ties the test article, the evidence, and the submitted standard, which is exactly the seam a reviewer pulls at.
What gets reviewed
- The configuration the evidence was generated against, established report by report
- The configuration of the test article, established from conformity and build records
- The configuration named in the submittal, established from the part standard and drawing tree
- The three reconciled, with every revision and effectivity difference identified
- Software and hardware revisions checked against the top-level configuration that should bound them
- A single reconciled baseline, or an explained and bounded difference, tying evidence to the submitted build
What gets validated
- Each test report's article configuration matches the configuration the submittal certifies
- Conformity records for the test article agree with the configuration the evidence claims
- Software and hardware revisions are bounded by the top-level configuration named in the submittal
- Every configuration difference between tested and submitted builds is identified and dispositioned
- Evidence references in the matrix point to reports generated on the submitted configuration
Evidence normally required
- The configuration management records: part standards, drawing trees, and revision history
- Conformity and build records for the test article
- The test reports and analyses, with the configuration each was generated against
- Software and hardware version and configuration identifiers
- The submittal's stated configuration and any reviewer comments on it
Common discrepancies
- A test report retaining an old part number after the submittal moved to a new one
- A late design change embodied in the shipped article but absent from the tested one
- Conformity records that do not match the configuration the evidence claims
- A software or hardware revision that the top-level configuration no longer bounds
What is at stake
A configuration mismatch undermines every result that depends on it, because a test proves compliance only for the configuration it ran on. If the shipped standard differs from the tested one, the evidence has to be shown still valid or the test rerun on the current build, and rerunning a campaign late is the outcome no program has room for. Left uncaught, the mismatch means the article in service is certified against evidence from a different configuration, which is the kind of gap that resurfaces at the worst possible time.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Establish the three builds
Fix the configuration of the evidence, the test article, and the submittal from their own records.
Find the differences
Trace revisions, effectivity, and conformity to locate every point where the three configurations disagree.
Disposition each gap
Decide revalidation, rerun, or bounded difference for each mismatch and identify the records needed.
Reconcile the baseline
Deliver a single reconciled baseline, or explained differences, with a disposition package.
What the buyer receives
- A closure brief listing every mismatch among evidence, test article, and submitted configuration
- An evidence request list for the conformity, revision, or re-baseline records needed
- A disposition package reconciling baseline, revisions, conformity records, and evidence references
Who uses the output
- Certification leadership deciding revalidation versus rerun for each configuration difference
- Engineering leads reconciling the drawing tree, conformity, and evidence configurations
- Program management judging schedule exposure from any tested-versus-shipped gap
How the work fits into the transaction or program
This ties the evidence, the article, and the submittal to one configuration, sitting between the build and conformity records and the compliance submittal. It catches the drift that independent processes create, so the package the supplier submits certifies the configuration it actually intends to ship.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both require that certification evidence correspond to the configuration being approved, and both treat a tested-versus-submitted mismatch as a finding. The reconciliation is authority-neutral, though a difference bounded and accepted under one authority still has to be shown bounded under the other where their submittals diverge.
Regulatory limits
The work reconciles configurations and identifies where they diverge. It does not perform conformity inspection, does not determine airworthiness, and does not accept a configuration on behalf of an authority; whether a bounded difference is acceptable stays with the authority.
What this review does not cover
- Performing conformity inspection of the test article
- Re-running the test campaign on the submitted configuration
- Design changes to align the tested and shipped builds
Specific to this review
- Three configurations have to agree, and each is maintained by a different process, which is why they drift apart quietly.
- A test result is valid only for the exact build it ran on, so any tested-versus-shipped difference puts that result in question.
- Software and hardware revisions can move independently of the top-level configuration, leaving a build the master configuration no longer bounds.
- A retained old part number on a report is a common tell: the evidence quietly describes a build the submittal has already left behind.
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
The article passed its tests and shipped. Why does the configuration still matter?
A test proves compliance for the exact configuration it ran on. If the article shipped in a different configuration than the one tested, whether from a late change or an independent software or hardware revision, the evidence no longer clearly covers the shipped build. Reconciling the configurations confirms the evidence still applies, or scopes what has to be revalidated, before a reviewer finds the seam.
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.