TSO authorization
Verification traceability support for TSO authorization
A TSO verification trace review confirms that each requirement recorded as verified is backed by a specific test, analysis, inspection, or review result rather than a bare status flag. Equipment suppliers use it before submission, so nothing is marked complete on the strength of an intended activity that never produced a result. It matches every verification claim to its evidence, checks that the evidence addresses the whole requirement rather than part of it, and finds requirements that show verified but have nothing recorded. You get a gap assessment on the verification claims, a map from each requirement to its verification result, and a closure plan for the claims that lack evidence.
When this review is needed
- Verification is nominally complete and the status needs to be proven against actual results before submission.
- A requirement is marked verified but the result behind it was never located or archived.
- A test partially covered a requirement and the rest was closed on assumption rather than evidence.
- Verification was distributed across teams and no one has reconciled the claims against the recorded results.
The problem
A verification status is trivial to set and expensive to substantiate. Requirements get marked complete when the activity is scheduled or believed done, and the flag says verified whether or not the result was captured, reviewed, and filed. The verification trace is where intended work masquerades as finished work, and it only unravels when someone asks to see the result behind a green line.
What gets reviewed
- Each verified requirement matched to a specific recorded result
- Coverage checked so the evidence addresses the entire requirement, not a fragment
- Test, analysis, inspection, and review results confirmed as captured and reviewed
- Requirements flagged verified with no retrievable result identified
- Verification evidence aligned with the DO-178C and DO-254 objectives it supports
- Results that pass but against an obsolete requirement or configuration flagged
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 resolves to a recorded, retrievable result
- The evidence for each requirement covers all of it rather than one condition of it
- Each result was reviewed and dispositioned, not merely run and set aside
- Verification against DO-160G, DO-178C, or DO-254 objectives ties to the right requirement
- No verified status rests on a result generated against a superseded configuration
Evidence normally required
Common discrepancies
- A requirement flagged verified with no result recorded anywhere
- A test that covered one condition recorded as verifying the whole requirement
- A result that was run but never reviewed or dispositioned
- Verification passed against a configuration the article has since superseded
What is at stake
A requirement marked verified without evidence is a hole a reviewer will find, and each one reopens work the schedule assumed was closed. Partial coverage recorded as full leaves a requirement genuinely unverified while the record says otherwise, which is the kind of gap that turns into a finding late and pulls the authorization date with it.
How the work runs
Pull the verified set
List every requirement marked verified and the result each claim points to.
Match claim to result
Confirm each result exists, was reviewed, and covers the whole requirement.
Check the configuration
Confirm results were generated against the current article, not a superseded one.
Close the empty claims
List verified requirements with no evidence and sequence the results still needed.
What the buyer receives
- A gap assessment on the verification claims and their evidence
- A map from each requirement to the verification result that closes it
- A closure plan for verified claims that lack supporting evidence
Who uses the output
- Certification leads who present verified status to the FAA and answer for it
- Verification owners tracking which claims still need a captured result
- Program managers seeing which verification the schedule counted as done but is not
How the work fits into the transaction or program
Verification traceability closes the upward half of the requirements trace, turning verified flags into evidence. It runs after verification activities are believed complete and before submission, and its closure plan drives the last results that have to be captured, reviewed, and filed.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
Verification evidence is organized to the DO-178C and DO-254 objectives the FAA applies for the article, so completeness is judged against FAA-accepted expectations. Where the article later goes to another authority, the evidence is reusable but the objective set is re-checked rather than assumed identical.
Regulatory limits
The review checks that verification claims are supported by real, reviewed results. It does not run the verification, judge the technical adequacy of a passing result, or make a finding that the requirement is met.
What this review does not cover
- Executing the tests, analyses, or inspections themselves
- Dispositioning verification results as pass or fail
- Issuing an FAA finding on the verified requirements
Specific to this review
- A verified flag is set by a person, not by evidence, so the status and the result routinely diverge until someone reconciles them.
- Partial coverage recorded as full is the quiet failure: the requirement reads verified while a condition of it was never exercised.
- A passing result against a superseded configuration is worse than a missing one, because it looks like proof while proving nothing about the current article.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
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
How is this different from the requirements trace review?
Requirements traceability confirms each requirement reaches design and has a verification link at all. This review goes further on the upward side and checks that the link resolves to a real, reviewed result covering the whole requirement, rather than a flag set on an activity that was only intended.
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.