STC finding closure
Closing configuration baseline mismatches in a STC program
This work resolves a STC finding where the configuration you tested, the configuration you submitted, and the configuration your evidence describes do not line up. An engineer reads the configuration management data, pins down exactly which item numbers, part numbers, and revisions diverge, and rebuilds one baseline that the conformity records and test reports actually support. It runs when a modifier is mid-program and a reviewer has flagged the baseline as inconsistent. You get a closure brief that states the reconciled baseline, an evidence request list for the records still missing, and a disposition package a certification reviewer can act on.
When this review is needed
- A reviewer has returned the submittal noting the tested configuration does not match the drawings and part lists submitted for approval.
- The test article was modified after the qualification run and the conformity records were never updated to the flown standard.
- Two revision levels of the same assembly appear in the data package and no one can say which one the approval rests on.
- A late design change closed one issue but its effectivity was never carried through the whole configuration set.
The problem
A modifier discovers late that the box tested on the bench, the drawing tree in the submittal, and the conformity paperwork each describe a slightly different build. Each divergence is small on its own, a superseded revision here, an uncontrolled jumper there, but together they mean no reviewer can trust that the evidence covers the configuration seeking approval. Tracing which record is authoritative takes people who understand both the change history and the certification data, and that time is rarely budgeted.
What gets reviewed
- The configuration management data compared line by line against the submitted drawing tree and part lists
- Test article configuration as run reconciled to the conformity and inspection records
- Revision and effectivity of each affected item traced to a single controlling standard
- Late design changes checked for full propagation through the configuration set
- The gap between as-built and as-submitted stated explicitly with the record that resolves each one
- A reconciled baseline expressed so the reviewer can map evidence to configuration
What gets validated
- Every item number in the submitted baseline resolves to one controlling revision with no competing level in the package
- The test article configuration recorded in the conformity data matches the standard the qualification reports describe
- Effectivity on each modified assembly is consistent between the drawing tree, the part list, and the change records
- Any post-qualification change to the article is either reflected in updated conformity or explained by analysis
- The reconciled baseline references evidence that actually exists in the package rather than a record still to be produced
Evidence normally required
- The configuration management plan and the controlled drawing and part lists for the modification
- Conformity inspection records and any test article build records
- Qualification and test reports with the as-run configuration stated
- The change log or engineering change records for the program
- The reviewer's finding text describing the baseline inconsistency
Common discrepancies
- A superseded assembly revision left in the submittal alongside the current one, with nothing saying which governs
- A test article change made after qualification that never reached the conformity records
- Effectivity that applies to one part list but was never carried into the matching drawing tree
- A part number in the conformity report that does not appear anywhere in the submitted configuration
What is at stake
If the baseline stays inconsistent, the reviewer cannot accept the evidence at face value, so the finding stays open and the program burns another review cycle. Worse, an approval granted against an unreconciled baseline can force a later data correction or a limitation once the mismatch surfaces in service, and by then the test article and the people who built it may be gone.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Assemble the three views
Pull the as-built, as-submitted, and as-tested configuration from the conformity, drawing, and report sets.
Locate each divergence
Identify every item number, revision, and effectivity where the three views disagree.
Rebuild one baseline
Establish the single controlling standard each affected item resolves to and the evidence behind it.
Package the disposition
Write the closure brief, list the records still needed, and tie each baseline line to its evidence.
What the buyer receives
- A closure brief stating the reconciled configuration baseline and the divergences it resolved
- An evidence request list naming the conformity or change records still needed to support the baseline
- A reviewer-ready disposition package linking each baseline item to its supporting evidence
Who uses the output
- Certification engineers assembling the response that answers the reviewer's finding
- Program managers who need the open finding cleared before the next review milestone
- Configuration management staff correcting the controlled records to the reconciled standard
How the work fits into the transaction or program
Baseline reconciliation sits between the raw configuration data and the reviewer's acceptance of the compliance evidence. Until the baseline is settled, every other finding that references a part number or revision is unstable, so this closure typically clears ahead of the ICA, qualification, and software or hardware findings that depend on knowing which configuration the approval covers.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
An FAA STC and an EASA approval of the same modification can reference different controlling data and conformity conventions, so the reconciled baseline is expressed against the basis the reviewing authority is actually working from rather than a single generic tree.
Regulatory limits
This work reconciles records and identifies the evidence that supports one baseline. It does not perform conformity inspections, approve the configuration, issue or amend a STC, or make any airworthiness determination, all of which rest with the applicant and the authority.
What this review does not cover
- Performing new conformity inspections on the test article or the modification
- Authoring or revising the underlying design or drawing data
- Any determination that the reconciled configuration is airworthy or approvable
Specific to this review
- The most damaging mismatch is usually a post-qualification change to the test article, because the flown standard no longer matches the reports the approval leans on.
- Two live revisions of one assembly in a package is not a clerical slip to a reviewer; it means the evidence could support either build, which supports neither.
- Effectivity errors hide well because a part list and its drawing tree are maintained by different people, so they drift apart quietly.
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
Can you fix the mismatch if the test article no longer exists?
Often yes, because the reconciliation works from the records. Where a post-qualification change cannot be shown in conformity data, we identify it plainly so the applicant can decide whether analysis or a limitation closes the gap. What we do not do is invent evidence for a configuration no record supports.
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.