Verification traceability
Verification traceability evidence review for aircraft modifiers
A verification trace evidence review confirms that the test, analysis, inspection, and review results in the package actually close the requirements they are credited against. It is run for aircraft modifiers before a submittal, in a finding response on verification adequacy, or after a change reopens previously closed requirements. The review targets requirements marked complete that lack the evidence to be complete, and verification results credited to a requirement they do not fully cover. You get a gap list of unsupported closures, an evidence map from each requirement to its verification, and a closure order.
When this review is needed
- A submittal claims a body of requirements verified and the closing evidence must stand behind each claim.
- A finding challenged whether a verification method or result adequately closed a requirement.
- A change reopened requirements whose earlier verification may no longer apply.
- Verification was split across test, analysis, inspection, and review and no one has confirmed the credited mix closes each requirement.
The problem
Marking a requirement verified is a status change; producing evidence that truly closes it is a body of work. The two drift apart. A requirement gets marked complete against a test that ran on an earlier configuration, or against an analysis that covers most but not all of the condition. The status board shows a solid column of green while several closures rest on evidence that is partial, stale, or credited to the wrong result.
What gets reviewed
- Each requirement marked verified matched to the specific result that closes it
- The verification method credited checked as adequate for the requirement, not merely present
- Test evidence confirmed to have run on the configuration the requirement applies to
- Analysis and inspection results checked to cover the full condition, not a subset
- Requirements reopened by change confirmed to have current verification rather than stale results
- Review-based verification confirmed to be recorded with enough substance to stand as evidence
What gets validated
- Every requirement marked verified points to an identifiable closing result
- The credited verification method is adequate to close the specific requirement
- Test data credited to a requirement was taken on the applicable configuration
- Analysis or inspection credited to a requirement covers the whole of its condition
- Requirements reopened by a change carry verification generated after the change
Evidence normally required
- The verification results set: test reports, analyses, inspection records, and review records
- The requirement set with each item's verification status
- The trace linking requirements to verification results
- Configuration records that fix which build each test ran on
- Change records that reopened previously closed requirements
Common discrepancies
- Requirements marked verified against a test run on a superseded configuration
- Analysis credited to a requirement that covers only part of its condition
- Review-based verification recorded too thinly to stand as evidence on its own
- Requirements reopened by a change still showing their pre-change verification as closed
What is at stake
Unsupported closures are the findings an authority is most likely to catch, because the claim is explicit and the missing evidence is checkable. Each one that surfaces late forces re-verification under schedule pressure, and a closure credited to superseded-configuration test data can invalidate a whole group of related requirements at once.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Match closures to results
For each requirement marked verified, identify the specific result credited with closing it.
Test adequacy and applicability
Check that the method is adequate and that the evidence ran on the applicable configuration and covers the full condition.
Screen change-reopened items
Confirm requirements reopened by change carry post-change verification rather than stale results.
Deliver unsupported closures
Return the closures the evidence does not support with an evidence map and a re-verification order.
What the buyer receives
- A gap list of closures that the credited evidence does not fully support
- An evidence map from each verified requirement to the result that closes it
- A closure order that re-verifies the stale and partial items first
Who uses the output
- STC program managers confirming the verified column will withstand scrutiny
- Certification engineers responding to a finding on verification adequacy
- Engineering leads scheduling the re-verification the review exposes
How the work fits into the transaction or program
Verification is where requirements turn into closed compliance, so it is the layer an authority probes hardest. Checking that each closure rests on adequate, current, applicable evidence keeps the compliance matrix and the certification claim standing on results that hold rather than on a status field.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both scrutinize configuration applicability of verification evidence, and both expect review-based verification to be substantiated rather than asserted. The review holds each closure to the governing authority's expectation for the method credited, rather than a generic pass criterion.
Regulatory limits
This review checks the modifier's verification evidence. It does not perform verification, does not make a compliance finding, and does not determine airworthiness. Judging verification sufficiency for approval remains with the authority.
What this review does not cover
- Running the test, analysis, or inspection that a closure is missing
- Re-authoring verification records for the modifier
- Presenting verification adequacy arguments to the authority
Specific to this review
- The configuration a test ran on is the detail closures fail on most, since a requirement can be genuinely verified on a build the change has since left behind.
- Partial analysis is a quiet defect: the result is real and correct as far as it goes, but it closes only part of the requirement's condition.
- Review-based verification is legitimate but often recorded too thinly, so the record cannot carry the closure the program credits to it.
- A change that reopens a requirement rarely clears its old verified flag automatically, so stale closures survive until someone checks.
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
Is this the same as the requirements trace review?
No. The requirements trace review checks that links exist in both directions. This review checks the evidence at the top of those links: whether the verification credited to a requirement is adequate, current, and run on the right configuration.
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.