Verification traceability
Verification traceability evidence review for avionics suppliers
This review checks whether the verification evidence behind an avionics package actually reaches every requirement it claims to satisfy. A certification specialist walks the trace from the requirement set down to the test, analysis, inspection, and review records, then back up again, so nothing is asserted closed on the strength of a matrix cell alone. It runs before a data submittal, during a finding response, or when a design change reopens requirements that were already verified. You leave with a gap list, an evidence map tied to each requirement, and a closure sequence certification leadership can work through.
When this review is needed
- A verification data package is about to be submitted and the team wants the trace pressure-tested first.
- An authority finding questions whether a specific requirement was actually verified or only claimed.
- A late design change reopens requirements that the matrix still shows as fully verified.
- Verification was split across software, hardware, and system teams and no one has walked the trace end to end.
The problem
Verification records accumulate faster than anyone can reconcile them. A requirement gets a test method assigned early, the test procedure changes twice, the results land in a different tool, and the matrix still reads verified because a cell was filled in months ago. The people who ran the analysis have moved to the next program, and the link from requirement to actual evidence lives in memory rather than in the record.
What gets reviewed
- Requirement set reconciled against the verification matrix so every entry has a stated method and a target artifact
- Test, analysis, inspection, and review evidence located and opened rather than merely cited
- Bidirectional trace confirmed from requirement to evidence and from evidence back to the requirement it closes
- Derived requirements checked for their own verification and their feedback to the safety assessment
- Requirements marked complete separated into supported, partially supported, and unsupported
- Method changes across procedure revisions checked so the cited result still matches the current requirement
What gets validated
- Each requirement marked verified resolves to an opened artifact, not a matrix reference that dead-ends
- The verification method recorded in the matrix matches the method the evidence actually documents
- Derived requirements carry their own verification and are visible to the safety assessment
- Evidence revision cited in the trace is the revision that was released, not a superseded draft
- Requirements touched by the latest change show verification re-run or a rationale for why re-run was unnecessary
Evidence normally required
- The requirement set at its current baseline with derived requirements identified
- The verification matrix or trace database as maintained
- Test procedures, results, analyses, and inspection and review records referenced by the matrix
- The plan that assigns verification methods and levels for the item
- Change records for any requirement modified since the last verification pass
Common discrepancies
- Requirements shown verified against a procedure revision that was later replaced
- Derived requirements with no verification method and no path into the safety assessment
- Matrix cells pointing to a tool or folder where the cited result no longer lives
- Analysis evidence that verifies an earlier requirement wording than the one now baselined
What is at stake
A trace that reads complete but does not resolve to evidence turns into a finding at exactly the wrong moment. The authority asks for the record behind one requirement, the record is not where the matrix points, and a submittal that looked ready stalls while the team rebuilds a link nobody kept. Every reopened requirement drags its neighbors with it.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Baseline the requirement set
Fix the current requirement baseline, flag derived requirements, and confirm the matrix reflects that baseline rather than an earlier one.
Open the cited evidence
Follow each verified entry to its artifact and open it, confirming method and revision rather than accepting the citation.
Trace both directions
Confirm requirement-to-evidence and evidence-to-requirement so orphaned results and unverified requirements both surface.
Sequence the closures
Sort the gaps by dependency and effort so the team closes enabling items before the ones that depend on them.
What the buyer receives
- A gap list naming each requirement whose verification evidence is missing, stale, or mismatched
- An evidence map linking every verified requirement to the artifact that closes it
- A closure sequence ordering the gaps by dependency and effort to close
Who uses the output
- Certification leadership deciding whether the verification package is ready to submit
- Verification engineers who need a concrete list of traces to rebuild or re-run
- The team drafting finding responses that must cite evidence an authority can open
How the work fits into the transaction or program
Verification traceability is the spine the rest of the certification data package hangs from. This review sits between the engineering that produced the evidence and the submittal that presents it, catching broken links while there is still time to fix them rather than after an authority has drawn 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 they reach it through different channels: FAA project guidance and delegated findings on one side, EASA panel review and means of compliance on the other. The trace itself has to satisfy both, so the review reads it against whichever basis and finding path the program is actually using.
Regulatory limits
This review reads the supplier's own verification evidence and reports where the trace holds and where it breaks. It does not make an airworthiness determination, does not issue or accept a compliance finding, and does not stand in for the authority's or the delegate's review of the data.
What this review does not cover
- Running or re-running the verification tests and analyses themselves
- Authoring the missing procedures, results, or analyses the gaps call for
- Rendering the compliance finding an authority or delegate reserves
Specific to this review
- Most broken traces are not missing evidence but evidence pinned to a requirement wording that has since changed, which a cell-count of the matrix never reveals.
- Derived requirements are the usual blind spot: they arise inside the design, so they are easy to verify and easy to leave out of the trace back to the safety assessment.
- A verified requirement can still fail review if the cited artifact is a draft revision the release process later superseded.
- Walking the trace backward from evidence to requirement finds orphaned test results that no requirement claims, which often signal a requirement that was dropped without closing its verification.
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 re-run the verification, or just check the trace?
The trace, not the verification. The review confirms that each verified requirement resolves to real evidence at the right revision and that the method matches. Where a gap needs a test re-run or a new analysis, the review names it and sequences it, and your engineers do the work.
Can you review the trace before the requirements are fully baselined?
It works best against a fixed baseline, because a moving requirement set produces gaps that are really just timing. If requirements are still settling, the review can run on the stable subset and flag the volatile requirements as a separate watch list.
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.