Verification traceability
Verification traceability evidence review for equipment suppliers
This review turns the question around from requirements to results: for every requirement a supplier calls verified, it confirms the test, analysis, inspection, or review evidence actually exists, addresses that requirement, and passed. It reads verification records against the requirements they claim to close and flags anywhere the claim outruns the evidence. A verification-literate engineer runs it before submittal, during a finding response, or when a design change invalidates prior results. The output is a gap list of requirements marked complete without supporting evidence, an evidence map, and a closure sequence for engineering leadership.
When this review is needed
- The verification matrix reports most requirements complete but the underlying records have never been read against those claims.
- A design change reran only part of the test campaign and the untouched results need to be re-qualified against the new configuration.
- A finding asks the supplier to show the evidence behind a batch of requirements marked closed.
- Verification was split across test, analysis, and vendor data and the method actually used per requirement is unclear.
The problem
Marking a requirement verified is a keystroke; producing the evidence that justifies it is not. Verification status tends to run ahead of the record: a requirement is called complete on the strength of a test that was planned, a report that is in draft, or an analysis that covered the earlier build. The matrix shows green while the folder behind it is thin.
What gets reviewed
- Confirmation that each verified requirement names a specific verification record and result
- Check that the record's method matches the method the requirement called for
- Read of pass or fail outcomes so requirements are not closed on inconclusive or failed runs
- Confirmation that the verified configuration matches the configuration being certified
- Identification of requirements marked complete with no locatable evidence at all
- Review of how partial reruns after a change left some evidence stale
What gets validated
- Every requirement marked verified points to a dated verification record with a recorded result
- The verification method in the record matches the method assigned to that requirement
- Results show a pass, with any deviations or limitations captured and dispositioned
- The article or build that was verified is the one the certification applies to
- Requirements closed on vendor or reused data have that data identified and current
Evidence normally required
- The verification matrix or status list showing which requirements are called complete
- Test reports, analysis reports, inspection records, and review records referenced by the matrix
- The requirement set with each requirement's intended verification method
- Configuration data identifying the article each record applies to
- Any change history that triggered partial reruns of the verification campaign
Common discrepancies
- Requirements marked verified against a test report still sitting in draft
- Analyses that closed a requirement but were run on a prior hardware standard
- Verification results with unresolved deviations treated as passes
- Reused vendor evidence closing a requirement without confirmation it covers this application
What is at stake
When a reviewer samples verified requirements and the evidence is not there, the credibility of the entire completion claim drops, and the sample widens. A supplier then faces re-running tests or reissuing reports on a compressed schedule, and a design change that arrives afterward can invalidate the very results that were finally assembled.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Pull the completion claims
List every requirement the matrix reports verified and locate the record each one cites.
Read the evidence
Confirm the method, result, and configuration of each record against what the requirement demanded.
Separate stale from missing
Sort gaps into evidence that never existed and evidence invalidated by a later change.
Sequence by effort
Order closures so rerun-heavy items start first and reissue-only items follow.
What the buyer receives
- A gap list of requirements marked complete without adequate verification evidence
- An evidence map linking each verified requirement to its record, method, and result
- A closure sequence prioritizing evidence that requires rerun over evidence that needs only reissue
Who uses the output
- Engineering leadership deciding which verification must be redone before submittal
- Certification leads defending the completion claim under authority review
- Verification engineers reissuing reports and closing out deviations
How the work fits into the transaction or program
Verification trace sits directly below requirements trace: once requirements reach test and analysis, this review confirms the results at the far end are real and current. Its findings feed the compliance map, because a method that relied on a verification now shown to be stale needs its map cell reopened.
Start with a single asset
Confirm requirements trace through verification.
Jurisdiction-specific considerations
DO-178C and DO-254 define verification objectives whose rigor scales with the assurance level, while ARP4754B expects system-level verification to close the safety-relevant requirements. FAA and EASA both look for the verified configuration to match the certified one, and this review flags where a rerun after a change left evidence tied to an earlier build.
Regulatory limits
This review checks that the supplier's verification claims are backed by evidence. It makes no airworthiness determination, approves no results, and does not decide whether the verification satisfies the applicable objectives. That acceptance belongs to the authority and its delegated engineers.
What this review does not cover
- Running or rerunning the tests, analyses, or inspections themselves
- Dispositioning deviations or writing the missing verification reports
- Judging whether the equipment performs adequately in service
Specific to this review
- Verification status drifts optimistic because closing a requirement is a status change while producing its evidence is a body of work, and the two rarely land on the same day.
- A partial rerun after a design change is the quiet killer: the reworked results are fresh, but the untouched ones now describe a configuration that no longer exists.
- A deviation dispositioned as acceptable is not the same as a pass, and requirements closed over open deviations are a recurring source of late findings.
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 traceability review?
Requirements traceability confirms each requirement reaches a verification activity. This review reads what that activity produced: whether the record exists, used the right method, passed, and applies to the certified configuration. A requirement can trace perfectly to a test that was never run, and that is exactly the case this review catches.
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.