Major change program
Verification traceability review for a major change program
This review checks the verification traceability of a major change, confirming that requirements marked complete are actually backed by test, analysis, inspection, or review evidence. A certification specialist reads each verified requirement down to the record that verifies it, finding the requirements shown complete with no evidence and the evidence that verifies a stale version of the requirement. The output separates genuinely verified requirements from those marked done on trust. You receive a gap assessment, a verification coverage map, and a closure plan before the trace supports the compliance claim.
When this review is needed
- Requirements are being marked verified and someone needs to confirm each mark has evidence behind it.
- Test, analysis, and inspection results came in across a long program and coverage was never reconciled as a whole.
- A requirement changed after it was verified and the old evidence may no longer prove the new wording.
- The compliance claim is about to rest on the verification trace and any hole in it weakens the claim.
The problem
Verification status is a checkbox, and a checkbox is faster to tick than the evidence behind it is to file. Across a long major change, results arrive from tests, analyses, inspections, and reviews at different times, and a requirement gets marked complete when its evidence is expected rather than when it is confirmed present. The trace then shows full coverage while some verified requirements point to results that never landed or that verified an earlier version of the requirement.
What gets reviewed
- Every requirement marked verified traced to the specific test, analysis, inspection, or review record
- The verification method confirmed appropriate to the requirement it closes
- Requirements shown complete with missing or expected-but-absent evidence identified
- Evidence checked against the current requirement version, not a superseded one
- Partial verification separated from full so a partially met requirement is not read as complete
- Coverage across test, analysis, inspection, and review reconciled as a whole
Scope this review
Tell us the asset, the event, and the evidence in scope, and we will outline a focused first engagement.
Identify what is missing against the means of compliance.
What gets validated
- Each requirement marked verified points to a real result record that exists and is complete
- The verification method matches what the requirement needs to be closed
- Evidence verifies the current version of the requirement, not a superseded one
- Partially verified requirements are marked partial rather than complete
- No requirement is shown complete on the expectation of evidence that has not landed
Evidence normally required
- The verification traceability data for the change
- The test, analysis, inspection, and review results the trace references
- The requirement set at current version, with change history
- The verification plan defining the method per requirement
- Any prior coverage reports on the change
Common discrepancies
- A requirement marked verified whose referenced result was never delivered
- Evidence that verifies an earlier version of a requirement the design has since changed
- A requirement closed by a method the plan does not consider adequate for it
- A partially met requirement recorded as fully complete
What is at stake
A requirement marked verified with no evidence is a hole in the compliance claim that an authority finds by pulling one thread, after which the whole coverage claim is in doubt. Evidence that verifies a superseded version of a requirement passes against something the design no longer does, so the requirement is unverified in fact while it reads as complete.
How the work runs
Read status to record
Take each requirement marked verified and open the result record it points to, flagging any that is missing.
Check method and version
Confirm the verification method suits the requirement and the evidence covers its current version.
Separate partial from complete
Identify requirements met only in part that the trace records as fully verified.
Close the coverage gaps
List the missing and stale evidence and sequence the verification work to close it.
What the buyer receives
- A gap assessment listing requirements verified in status but not in evidence
- A verification coverage map tying each closed requirement to its result record
- A closure plan for the missing and stale verification evidence
Who uses the output
- Certification leadership confirming coverage before the compliance claim rests on it
- Engineering leadership sourcing the missing or updated verification evidence
- Compliance managers tracking which verified requirements still lack evidence
How the work fits into the transaction or program
The verification review runs after the requirements trace is sound and the results are largely in, because it confirms the last link in the chain from requirement to proof. It sits directly under the compliance claim, so a hole caught here is closed with a test or analysis while catching it at authority review is a finding against a claim already made.
Start with a single asset
Reduce finding cycles by checking the package first.
Regulatory limits
The review confirms that verified requirements are backed by real, current evidence and that the coverage is whole. It does not perform the verification, judge the technical adequacy of a result, or make any compliance or airworthiness finding.
What this review does not cover
- Running the tests, analyses, or inspections that produce the evidence
- Judging the technical adequacy of a verification result
- Any compliance or airworthiness determination on the change
Specific to this review
- Verification status is a checkbox that outruns its evidence, because a requirement gets ticked complete when its result is expected, not when it is confirmed on file.
- Evidence tied to a superseded requirement version passes against something the design no longer does, so the requirement is unverified in fact while it reads as complete.
- Coverage reconciled requirement by requirement over a long program is the only way to catch the results that were expected but never landed.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
Federal Aviation Administration. FAA type certification process, certification basis establishment, and compliance findings.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
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).
Frequently asked questions
How is this different from checking our requirements trace?
The requirements trace confirms the requirement set is complete and linked to design and verification. This review confirms the verification side actually happened: that each requirement marked verified has a real result behind it, against the current version of the requirement.
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.