Verification traceability
Verification traceability review for qualification test teams
A verification traceability review confirms that the test, analysis, inspection, and review evidence a program claims is complete truly closes the requirements it is credited against. It is run for a qualification test team before a data submittal, a finding response, or a change that reopens verification. The reviewer starts from requirements marked closed and works back to the evidence, catching the cases where a requirement reads complete but the artifact behind it is missing, partial, or from a superseded configuration. You receive a gap list, a verification map, and a sequence for producing the evidence that is not there.
When this review is needed
- Verification reads complete and the team wants that confirmed before the data goes out.
- An authority asked to see the evidence closing a specific block of requirements.
- A design change invalidated part of the verification and the closure status has to be reworked.
- Verification ran across several test campaigns and no one has reconciled the results to the requirements.
The problem
Verification status is where optimism accumulates. A requirement gets marked verified when a test is scheduled, when a result is expected, or when a related requirement passed, and the actual artifact never quite catches up. Multiply that across campaigns and configurations and the closure count looks done while a real fraction of it rests on evidence that is missing, ran against an old build, or only partly covers the requirement it claims to close.
What gets reviewed
- Requirements marked verified traced back to the specific test, analysis, inspection, or review evidence
- Evidence checked for whether it fully closes the requirement or only touches it
- Verification results confirmed to come from the configuration under certification
- Method used checked against the method the requirement calls for
- Requirements reopened by a design change confirmed to have current evidence
- Closure status reconciled across separate verification campaigns
What gets validated
- Every requirement marked verified points to a retrievable evidence artifact
- The evidence covers the full requirement rather than a subset of its conditions
- The result was produced against the configuration being certified, not a prior build
- The verification method matches what the requirement and the basis call for
- Requirements touched by a change carry evidence from after the change, not before
Evidence normally required
- The verification status list showing which requirements are marked closed
- Test reports, analysis records, inspection results, and review records
- The requirements baseline and the assigned verification methods
- The configuration record for the article each result was produced on
- The change history that reopened or invalidated prior verification
Common discrepancies
- A requirement marked verified with no evidence artifact behind it
- Test evidence that covers part of a requirement but is credited with all of it
- A result produced against a build that has since been superseded
- A requirement verified by a method the basis does not accept for it
What is at stake
A requirement marked verified with no evidence behind it is a direct finding, and it usually travels in a cluster, because the same optimistic bookkeeping repeats across a campaign. Discovering it late means running verification under submittal pressure or, worse, rerunning tests against the current configuration because the original result came from a superseded build. Both blow the schedule the closure count was supposed to protect.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Start from closed
Take the requirements marked verified and work backward to the evidence rather than forward from the tests.
Test coverage and currency
Confirm each artifact fully covers its requirement and came from the current configuration.
Reconcile across campaigns
Align closure status where verification spanned multiple campaigns or configurations.
Sequence the reruns
Order the missing and stale evidence by the submittal blocks it holds up.
What the buyer receives
- A gap list of requirements closed without sufficient current evidence
- A verification map linking each requirement to its actual evidence
- A sequence for producing or rerunning the evidence that is missing
Who uses the output
- Test leadership deciding which verification to rerun before submittal
- Certification leadership defending closure status to an authority
- Engineering leads scheduling the evidence still owed against the current build
How the work fits into the transaction or program
This review sits downstream of the requirements-trace pass and upstream of the submittal. Where the requirements trace confirms a requirement has a path to verification, this confirms the verification actually happened and closed it. Its gap list feeds the compliance matrix, which cannot honestly show a requirement complete until the evidence behind it is confirmed present and current.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
The FAA and EASA both expect verification evidence to trace to requirements, but they differ on how much independence and how much configuration control they expect to see documented around a result. The review notes where evidence acceptable to one authority would need additional configuration provenance to satisfy the other on a dual-validation program.
Regulatory limits
The review confirms that claimed verification is backed by real, current evidence. It does not perform verification, judge whether a passing result is correct, or make a compliance finding. Acceptance of the evidence as closing a requirement stays with the authority.
What this review does not cover
- Running or rerunning any verification activity
- Judging the technical correctness of a test or analysis result
- Any compliance determination on the verified requirements
Specific to this review
- Verified status inflates quietly, because a requirement often gets marked closed when a result is expected rather than when the artifact lands.
- A result from a superseded build is worse than a missing one: it reads complete but has to be rerun against the current configuration.
- Partial coverage is the subtle failure, where evidence exercises some of a requirement's conditions and is credited with all of them.
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
How is this different from the requirements-trace review?
The requirements-trace review confirms a requirement has a path to verification. This one confirms the verification actually ran, closed the whole requirement, and came from the configuration under certification. A requirement can trace cleanly yet still be marked verified against evidence that is missing or stale.
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.