Verification traceability
Verification traceability evidence review for hardware assurance teams
A verification-trace evidence review confirms that each requirement claimed as verified is supported by a test, analysis, inspection, or review record that a certification authority can follow. It is run by a hardware assurance team ahead of a data submittal, a finding response, or a design-change assessment. The review walks each verification link from the requirement through the method to the record and flags requirements marked complete with no evidence behind them. You get a gap list, an evidence map tying requirements to records, and a closure sequence the assurance lead can work through.
When this review is needed
- A data package is about to be submitted and the team wants no requirement marked verified without a record behind it.
- An authority finding questioned a verification claim and the response has to point to specific evidence.
- A design change reopened requirements and the affected verification links need to be re-walked.
- A trace matrix was assembled from several tools and no one has confirmed the links resolve end to end.
The problem
A verification matrix can show every requirement as covered while the records behind it tell a different story. Links get entered by hand, methods change late, and a test that was descoped can leave a requirement marked verified against a plan that never ran. By the time an authority follows one of those links to a missing record, the submittal is already in review and the credibility of the whole matrix is in question.
What gets reviewed
- Each verified requirement walked from the statement through its assigned method to the supporting record
- Test, analysis, inspection, and review evidence checked for presence and currency against the claim
- Verification methods reconciled to what the plan committed for that requirement
- Requirements marked complete with no retrievable evidence flagged as open
- The link from verification back to the certification basis confirmed for each claim
- Derived requirements checked for verification coverage alongside the allocated set
What gets validated
- Every requirement shown as verified resolves to a record an authority could open and accept
- The verification method on record matches the method the plan committed for that requirement
- Analysis results cited as evidence are the current revision, not a superseded run
- Requirements added or changed by a late modification carry verification that reflects the change
- Derived requirements are verified rather than left implicit under a parent
Evidence normally required
- The requirements set with verification status and assigned methods
- The verification matrix or trace database linking requirements to evidence
- Test, analysis, inspection, and review records referenced by the matrix
- The certification basis and plan that fix the required verification methods
- Any change records that reopened requirements since the last trace pass
Common discrepancies
- A requirement marked verified against a test that was descoped before it ran
- A verification link that points to a record revision that no longer exists
- A derived requirement with no assigned verification method at all
- A method on record that does not match what the plan committed for that requirement
What is at stake
A broken verification link found by the authority rather than the team turns into a finding, and one finding invites a wider look at the matrix. Requirements that cannot be shown as verified hold up the compliance finding, and reconstructing evidence after submittal costs more schedule than confirming it beforehand ever would.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Pull the verified set
Assemble every requirement the matrix marks as verified, with its assigned method and cited record.
Walk each link
Follow the requirement through its method to the record and confirm the record exists and is current.
Flag the hollow claims
List requirements marked verified with no retrievable or matching evidence behind them.
Sequence the closure
Order the open links by dependency and effort so the team clears them before submittal.
What the buyer receives
- A gap list of requirements marked verified without supporting evidence
- An evidence map tying each requirement to the record that verifies it
- A closure sequence ordering the open links by dependency and effort
Who uses the output
- Assurance leads who have to sign the matrix as complete before submittal
- Certification leads answering an authority finding on a specific verification claim
- Engineering owners rerunning verification for requirements a change reopened
How the work fits into the transaction or program
The review sits between requirement closure and data submittal, taking the trace matrix the team has built and confirming it holds before an authority follows it. Its gap list feeds the verification work that has to finish, and its evidence map becomes the reference the submittal and any later finding response point back to.
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 the acceptable means and the way findings are recorded differ between them. The review notes where a verification claim satisfies one authority's expectation but would need additional evidence or a different method statement to satisfy the other.
Regulatory limits
The review checks that verification evidence is present and traceable. It does not perform the verification itself, accept a means of compliance on an authority's behalf, or make any airworthiness or compliance determination.
What this review does not cover
- Running or rerunning any test, analysis, or inspection
- Authoring the verification method or the requirements it traces to
- Deciding whether a means of compliance is acceptable to the authority
Specific to this review
- A matrix that shows full coverage is the most dangerous kind, because the gaps hide inside links that were never walked to the record.
- Descoped tests are a frequent source of hollow verification claims, since the requirement often stays marked verified after the test is cut.
- Derived requirements are where verification coverage silently drops, because they surface late and are easy to leave implicit under a parent.
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
Do you rerun the verification you find missing?
No. The review identifies which requirements lack traceable evidence and sequences the work, but the verification itself is run by the team that owns the method. The output tells them exactly which links to close and in what order.
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.