Verification traceability
Verification traceability evidence review for quality teams
This review confirms that the verification evidence behind a package reaches every requirement the trace marks complete, so a requirement is never closed on a matrix entry alone. A certification specialist walks the trace from the requirement down to the test, analysis, inspection, and review records and back up with your quality function, checking each closed requirement against real evidence. It runs before submittal, during a finding response, or when a change reopens requirements already verified. You receive a gap list, an evidence map keyed to each requirement, and a closure sequence for quality leadership.
When this review is needed
- A verification package is nearly ready and quality wants each completed requirement confirmed against real evidence.
- A finding disputes whether a requirement was actually verified or only marked so on the trace.
- A change reopens requirements the verification trace still shows as fully closed.
- Verification ran across test, analysis, and review teams and no one has confirmed every closure has evidence under it.
The problem
Verification closures accumulate faster than anyone reconciles them. A requirement is marked verified when a method is assigned, the test procedure is revised twice, the result lands in a separate tool, and the trace still reads complete because the entry was made early. The engineer who ran the analysis has moved on, and the link from a closed requirement to the record that closes it lives in memory, not in the file quality has to defend.
What gets reviewed
- Each requirement marked verified confirmed against the test, analysis, inspection, or review record that closes it
- Cited verification evidence located and opened rather than accepted on a trace reference
- The verification method recorded checked against the method the evidence actually documents
- Requirements marked complete separated into supported, partially supported, and unsupported closures
- Requirements touched by the latest change checked for re-verification or a rationale for why none was needed
What gets validated
- Each verified requirement resolves to an opened record, not a trace entry that dead-ends
- The verification method in the trace matches the method the evidence documents
- The evidence revision cited is the one released, not a superseded procedure or draft result
- Requirements marked complete but touched by a change show re-run verification or a written rationale
- No requirement reads verified against a result that actually addresses a different requirement
Evidence normally required
- The verification trace or matrix as maintained, with closure status per requirement
- The requirement set at its current baseline
- Test procedures, results, analyses, and inspection and review records the trace cites
- The plan assigning verification methods and levels for the item
- Change records for any requirement modified since verification closed
Common discrepancies
- A requirement marked verified against a procedure revision the release process later replaced
- A trace entry pointing to a tool or folder where the cited result no longer lives
- A closure resting on a result that verifies an earlier requirement wording than the one baselined
- A requirement reopened by a change but still carried as verified on the trace
What is at stake
A closure that does not resolve to evidence becomes a finding at the moment it can least be absorbed. The reviewer asks for the record behind one verified requirement, the record is not the revision the trace cites or is not there at all, and a package quality already cleared goes back into rework. Every reopened requirement drags the ones verified alongside it, and the schedule commits against a completion that was partly on paper.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Baseline the requirements
Fix the current requirement baseline and confirm the verification trace reflects it rather than an earlier one.
Open the cited evidence
Follow each verified requirement to its record and open it, confirming method and revision instead of trusting the entry.
Trace both directions
Confirm requirement-to-evidence and evidence-to-requirement so orphaned results and hollow closures both surface.
Sequence the closures
Order the gaps by dependency and effort so enabling verifications are re-evidenced before those built on them.
What the buyer receives
- A gap list naming each verified requirement whose evidence is missing, stale, or mismatched
- An evidence map linking every closed requirement to the record that verifies it
- A closure sequence ordering the gaps by dependency and effort to close
Who uses the output
- Quality leadership deciding whether the verification package is ready to release
- Verification engineers who need a concrete list of closures to rebuild or re-run
- The team drafting finding responses that must cite evidence a reviewer can open
How the work fits into the transaction or program
Verification traceability is where the certification data package proves its requirements were actually met, so a closure with no evidence is the failure a reviewer is quickest to find. This review runs between the verification work and the submittal that presents it, catching hollow closures while there is still time to re-evidence them rather than after a reviewer reaches the same conclusion.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
FAA and EASA both expect verification to trace to the certification basis, but reach it differently: FAA project guidance and delegated findings on one side, EASA review items and means-of-compliance acceptance on the other. The verification evidence has to satisfy both, so the review reads each closure against whichever basis and finding path the program is filing under.
Regulatory limits
This review reads your own verification evidence and reports where each closure holds and where it breaks. It does not make an airworthiness determination, does not issue or accept a compliance finding, and does not replace the authority's or the delegate's review of the verification data.
What this review does not cover
- Running or re-running the verification tests and analyses
- Authoring the missing procedures, results, or analyses a gap calls for
- Rendering the compliance finding an authority or delegate reserves
Specific to this review
- Most hollow closures are not missing evidence but evidence pinned to a requirement wording that has since changed, which a completion count never exposes.
- A verified requirement can still fail review when the cited record is a draft revision the release process later superseded.
- Walking the trace backward from evidence finds orphaned results no requirement claims, which often mark a requirement dropped without closing its verification.
- A change that reopens a requirement rarely reopens its trace entry, so a requirement can read verified while the work behind it has been invalidated.
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 does this differ from a requirements traceability review?
A requirements trace review checks that the structure connects: requirements to design to verification, with derived and changed requirements present. This review checks the verification end specifically, confirming that each requirement marked verified resolves to a real, current record. One tests whether the links exist; this tests whether the evidence at the end of them holds.
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.