STC certification
Verification traceability support for an STC program
This review readies the verification traceability behind an STC, so every requirement marked verified points to evidence that actually closes it. It is run for an aircraft modifier or equipment supplier as verification evidence accumulates. The work checks that test, analysis, inspection, and review evidence maps to the requirements it is supposed to close, that the method used matches what the requirement needs, and that no requirement is marked complete without evidence behind it. You receive a gap assessment of the verification coverage, an evidence map from each requirement to the results that close it, and a closure plan for the requirements marked complete but not yet proven.
When this review is needed
- Verification is winding down and each requirement marked complete has to point to real closing evidence.
- A requirement was closed by analysis that a later design change made no longer applicable.
- Test evidence exists but was never linked back to the requirements it was meant to close.
- The submittal will be examined for whether completion status matches the verification evidence in hand.
The problem
Verification status runs ahead of verification evidence. A requirement gets marked complete when the test is scheduled or the analysis is drafted, not when the result is signed and linked. Evidence gets generated but filed by test campaign rather than by requirement, so the link back is never made. A method that closed a requirement is invalidated by a design change and the completion flag stays green. The status board looks finished while some completions have no evidence attached to them.
What gets reviewed
- Test, analysis, inspection, and review evidence mapped to the requirements each closes
- The verification method checked for suitability to what the requirement demands
- Requirements marked complete confirmed to have signed, linked closing evidence
- Verification invalidated by a later design change flagged and reopened
- Evidence filed by campaign linked back to the requirements it verifies
- Requirements complete in status but unproven in evidence collected into a closure plan
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Every requirement marked verified points to a signed result that closes it
- The verification method used is appropriate to what the requirement actually demands
- Evidence generated by test or analysis is linked to the specific requirements it closes
- A verification invalidated by a design change is reopened rather than left counted as complete
- Completion status across the requirement set matches the evidence actually in hand
Evidence normally required
- The requirement set with its current verification status
- The test reports, analyses, inspection records, and review results
- The verification plan defining the method for each requirement
- The design change history that may have invalidated a verification
- The certification basis and standards defining the verification expectations
Common discrepancies
- A requirement flagged complete with no signed result linked to it
- A verification closed by analysis that a later design change invalidated
- Test evidence filed by campaign that was never traced to the requirements it closes
- A method used that does not actually verify what the requirement demands
What is at stake
A requirement marked complete without closing evidence is an open requirement wearing a green flag, and a reviewer who follows the flag to nothing raises a finding and distrusts the rest of the status. A verification invalidated by a design change but still counted as closed means a requirement is effectively unverified. Both are worst discovered at submittal, when reworking verification means schedule the program no longer has.
How the work runs
List what must close
Take the requirement set and its verification status as the reference for coverage.
Match evidence to requirement
Link each test, analysis, and inspection result to the requirements it closes.
Check method and currency
Confirm the method suits the requirement and no result was invalidated by a later change.
Reconcile and plan
Reopen unproven completions and plan the verification still owed.
What the buyer receives
- A gap assessment of verification coverage against the requirement set
- An evidence map from each requirement to the results that close it
- A closure plan for the requirements marked complete but not yet proven
Who uses the output
- Certification engineers assembling the verification evidence for submittal
- Test and analysis leads confirming their results are linked to the right requirements
- Program managers tracking true verification completeness against the status board
How the work fits into the transaction or program
Verification traceability closes the loop that requirements traceability opened, confirming that what the design implements is also proven. This review runs as verification finishes and before the submittal is compiled, so it draws on the requirement trace to know what must be closed and feeds the compliance matrix the confirmed evidence each requirement rests on.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both examine whether completion status is backed by evidence, and the acceptable verification method can differ between them for some requirements, so the review checks method suitability against the basis the examining authority will apply.
Regulatory limits
The review confirms verification status matches the evidence in hand. It does not perform or witness the verification, accept a result on the authority's behalf, or grant the STC.
What this review does not cover
- Performing or witnessing the test, analysis, or inspection
- Approving a verification result or its method
- Any authority acceptance of the verification or the STC
Specific to this review
- Verification status is marked when work is planned and evidence is linked when work is done, so status routinely leads evidence and the two have to be reconciled.
- Evidence filed by test campaign rather than by requirement is a frequent break point, because the result exists but the link that makes it count was never made.
- A verification invalidated by a design change is the hardest kind to catch, because the completion flag stays green while the result underneath it stopped applying.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
How can a requirement be marked complete without evidence?
Completion often gets flagged when a test is scheduled or an analysis is drafted, before the signed result is produced and linked. Evidence also gets filed by test campaign and never traced back to the requirement. Either way the status board reads complete while the closing evidence is missing, which the review finds by following each flag to its result.
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.