Verification traceability
Verification traceability evidence review for certification teams
A verification traceability evidence review checks that every requirement the project reports as verified is backed by test, analysis, inspection, or review evidence that actually confirms it. It is run for a certification team before submittal, during a finding response, or ahead of a design change review, by or for the team that owns the verification record. The work reads the verification evidence against the requirements it claims to close and against the certification basis, then flags every requirement marked complete with no substantiating result behind it. You receive a gap list, an evidence map from each closed requirement to its result, and a closure sequence compliance management can drive.
When this review is needed
- A requirement is marked verified but the test or analysis report that closes it cannot be produced.
- A verification method changed from test to analysis mid-program and the recorded result still reflects the old method.
- A requirement was revised after its verification ran, and no one confirmed the old result still covers the new wording.
- The team is preparing to submit and wants every closed requirement backed by a retrievable result.
The problem
Verification status is tracked as a state on a requirement, and states are easy to advance faster than the evidence behind them settles. A requirement is marked verified when a test is expected to pass, a partial result is recorded as complete, or a method is switched and the status carries over without the new evidence. The verification report shows a high completion percentage, but a share of those closures rest on results that are provisional, superseded, or missing outright.
What gets reviewed
- Each requirement marked verified reconciled to the test, analysis, inspection, or review that closes it
- The recorded verification method checked against the evidence that actually exists
- Partial or provisional results checked so they are not recorded as complete closures
- Verification of changed requirements checked so an old result still covers the new wording
- Pass or fail dispositions checked so a failed or conditional result is not silently marked complete
- Evidence retrievability confirmed so each cited result can actually be produced
What gets validated
- Every requirement marked verified cites a specific, retrievable result that confirms it
- The verification method recorded matches the method the evidence was actually produced by
- No partial or provisional result is carried as a complete verification closure
- A requirement changed after verification shows its result was re-examined against the new wording
- Every failed or conditional result is dispositioned rather than closed as passing
Evidence normally required
- The verification traceability matrix or database in its current state
- The test, analysis, inspection, and review reports cited as evidence
- The requirements baseline the verification is claimed against
- The verification method history where methods changed
- The change history for requirements revised after verification
Common discrepancies
- A requirement marked verified whose closing report cannot be retrieved
- A verification recorded as test but supported only by an analysis result
- A partial result carried as a complete closure
- A conditional or failed result marked verified without a disposition
What is at stake
A requirement marked verified with no result behind it is a hole precisely where the package claims to be strongest, and a reviewer who opens one such closure will doubt every other. When a verification method changed but the recorded evidence did not, the requirement is confirmed by a result that no longer applies, and untangling that late can send tests back onto a closed schedule.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Open each closure
For every requirement marked verified, retrieve the result that is supposed to confirm it.
Match method to evidence
Confirm the recorded verification method matches how the evidence was actually produced.
Test the completeness
Check that partial, provisional, or failed results are not carried as complete.
Sequence re-verification
Order the re-verification and disposition work against the submittal date.
What the buyer receives
- A gap list identifying each closure with no substantiating result behind it
- An evidence map linking every verified requirement to the result that confirms it
- A closure sequence ordering the re-verification and disposition work against submittal
Who uses the output
- Compliance managers confirming every closure is backed before the package is submitted
- Certification leads deciding which unsupported closures must be re-verified first
- Engineering owners dispositioning results that were marked complete prematurely
How the work fits into the transaction or program
Verification traceability is the downstream half of the requirement thread: requirements traceability proves each requirement had a verification obligation, and this review proves the obligation was actually met. Checking it before submittal exposes the premature closures that inflate a completion percentage, and the substantiated map it produces is what the compliance matrix and the certification findings ultimately rest on.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both require verification evidence traced to requirements, but they can differ on how much independence a verification result needs and on how conditional dispositions are documented. Where a project is certified under both, the review notes where a result acceptable to one authority needs additional independence or documentation to hold under the other.
Regulatory limits
The review confirms the verification evidence exists and confirms the requirements it is claimed against. It does not perform verification, disposition a failed result on the authority's behalf, or determine that a requirement is met.
What this review does not cover
- Running the tests, analyses, or inspections that would close a requirement
- Dispositioning a failed result on the authority's behalf
- Any determination that verification is complete or acceptable
Specific to this review
- Verification status is a state that can advance ahead of its evidence, so a high completion percentage can rest on closures that were marked before the results settled.
- A method switch is a quiet failure mode: the status stays verified while the evidence behind it belongs to the method the project no longer uses.
- A single unsupported closure damages credibility out of proportion to its size, because it makes a reviewer question every other closure in the package.
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
What is the most common reason a verified requirement has no evidence?
Status is advanced in anticipation. A requirement is marked verified when a test is expected to pass or a result is recorded as complete while it is still partial. The state moves faster than the evidence settles, so the review re-opens each closure and confirms a retrievable result actually stands behind it.
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.