Verification traceability support for installation approval packages

When this review is needed

• A requirement set has grown across several design iterations and no one has confirmed each line still points to current evidence.
• Verification was split across a test lab, an analysis team, and inspection reports, and the threads were never joined into one view.
• The project is weeks from submittal and needs to know which requirements are genuinely closed versus marked closed.
• A reviewer's first pass is expected to sample the trace, and the team wants to find the broken links before that sample lands on one.

The problem

Requirements and evidence usually mature in separate places. The requirement set lives in one tool, test reports pile up in another, and analysis memos and inspection records travel with the engineers who wrote them. A requirement can read as verified in the matrix while the artifact behind it is an older revision, sits under a different requirement number, or was never actually filed. That mismatch is invisible until someone tries to pull the evidence for a specific line.

What gets reviewed

• Each requirement in the certification basis paired with its assigned verification method and closing artifact
• Test, analysis, inspection, and review evidence checked for the revision the requirement actually references
• Derived requirements confirmed to carry their own verification rather than inheriting a parent's closure
• Requirements marked complete whose evidence cannot be retrieved isolated as open items
• The trace direction checked both ways so no requirement is orphaned and no evidence is unlinked
• A closure plan sequencing the unsupported lines by the effort each one needs

What gets validated

• Every requirement resolves to a retrievable artifact at the revision the matrix cites, not a superseded one
• Each verification method matches the requirement type rather than defaulting every line to test or to review
• Derived requirements introduced during design carry independent verification evidence
• No evidence artifact is left unlinked to a requirement, which usually signals a requirement was dropped
• The map accounts for every requirement line, whether verified, open, or deferred, with none silently missing

Evidence normally required

• The requirement set and the certification basis it derives from
• Test reports, analysis memos, inspection records, and review minutes as filed
• The verification method assigned to each requirement
• The current design and configuration baseline the requirements track to
• Any prior verification matrix or partial trace already assembled

Common discrepancies

• A requirement marked verified against a test report from an earlier design revision
• A derived requirement with no verification of its own, closed on the strength of its parent
• An analysis memo that exists but was never linked back to the requirement it satisfies
• A requirement number that appears in the matrix but has no evidence filed anywhere

What is at stake

A verification thread that breaks under sampling costs the project its credibility for the rest of the review. Once a reviewer finds one requirement closed without producing evidence, the review widens to lines that were fine, and the schedule absorbs a round of requests for information that a clean trace would have avoided. Requirements discovered unverified late leave no room to run the missing test or analysis before the review window closes.

How the work runs

What the buyer receives

• A requirement-to-evidence map covering every line in the certification basis
• A gap assessment naming each requirement that cannot produce its evidence
• A closure plan sequencing the open lines by the work each needs before submittal

Who uses the output

• Certification project managers deciding whether the package is ready to submit
• Engineering leads assigning the missing test or analysis to close open lines
• Compliance staff who will defend the trace when a reviewer samples it

How the work fits into the transaction or program

The trace sits underneath the compliance matrix and the accomplishment summary the modifier submits. It is the layer that proves what those higher documents assert, so it is assembled before them and refreshed whenever a design revision moves the evidence. Open lines it surfaces feed the test, analysis, or document-retrieval work the project runs ahead of formal review.

Jurisdiction-specific considerations

An FAA and an EASA reviewer read a verification thread the same way at the requirement level, but the acceptable means of compliance cited against a given requirement can differ between the two systems. The trace records which means each closure relies on so a package aimed at both authorities does not present one authority's basis as if it satisfied the other.

Regulatory limits

The work organizes and checks the verification evidence the modifier already holds. It does not perform the underlying tests or analyses, does not make a compliance finding, and does not grant or predict any approval. The authority determines compliance from the submitted package.

What this review does not cover

• Running the tests or analyses behind an open requirement
• Writing the requirements or setting the certification basis
• Issuing any compliance finding or approval on the authority's behalf

Specific to this review

• Derived requirements are the most common broken link because they appear during design and are easy to close on a parent's evidence rather than their own.
• A trace has to be walked in both directions: orphaned evidence usually means a requirement was quietly deleted while its proof stayed in the file.
• Revision drift breaks more threads than missing evidence does, since a requirement often points at a valid artifact that belongs to a prior design iteration.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits