Type-design packages
Verification traceability support for a type-design data package
This review checks the other half of the trace: whether the verification evidence in a type-design data package genuinely closes the requirements it is claimed against. It reads test, analysis, inspection, and review results and confirms each maps to a requirement, covers the whole of it, and shows a passing result rather than an incomplete or conditional one. A certification engineer runs it so no requirement is marked verified on evidence that does not carry it. You get a coverage assessment, a list of requirements verified in name only, and a plan to close the shortfalls.
When this review is needed
- Verification is reported complete and the applicant wants to confirm the evidence actually covers each requirement.
- A requirement was verified by a mix of methods and it is unclear whether the combination closes it fully.
- Test results include conditional passes or deviations and their effect on verification status is unresolved.
- The package is nearly ready and the team needs to know which verified requirements are backed only on paper.
The problem
Marking a requirement verified is a checkbox; earning it is a document that shows the requirement met, in full, under the right conditions. Evidence gets attached because it addresses the same subject, not because it covers the exact requirement, and partial coverage passes for complete. Deviations, retests, and conditional results sit in the reports and quietly undercut a status that the matrix reports as green.
What gets reviewed
- Each requirement marked verified traced to the specific evidence claimed against it
- The evidence checked for coverage of the whole requirement, not a subset
- Verification method confirmed appropriate for the requirement type
- Deviations, conditional passes, and retests assessed for their effect on status
- Requirements verified by combined methods checked for gaps between the methods
- Verification results reconciled against the current requirement wording, not a prior version
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
- Every verified requirement names the evidence that verifies it and that evidence exists
- The cited evidence covers the full scope of the requirement, including any bounds or conditions
- The verification method used is acceptable for that class of requirement
- Conditional or deviated results carry a resolution that keeps the requirement closed
- Where multiple methods verify one requirement, together they leave no part unaddressed
Evidence normally required
Common discrepancies
- Requirements marked verified where the evidence covers only part of the requirement
- Conditional passes carried as full verification with the condition never closed
- Analysis cited for a requirement that the certification basis expects to be tested
- Verification results tied to a superseded version of the requirement
What is at stake
When a reviewer samples a verified requirement and the evidence covers only part of it, the credibility of the whole verification set drops, and the review widens. Requirements verified on incomplete or conditional evidence may have to be reworked or retested late, and a retest can cascade into others that depended on the same setup. Schedule and cost land at the worst possible point, just before approval.
How the work runs
Pull the verified set
List every requirement marked verified and the evidence each one claims.
Test coverage
Read the evidence against the full requirement and mark where coverage falls short of the wording.
Resolve conditions
Assess deviations, conditional passes, and retests for their real effect on verification status.
Order the shortfalls
Sequence the gaps, flagging any that need a retest so they start first.
What the buyer receives
- A coverage assessment rating each verified requirement against its evidence
- A shortfall list of requirements verified in name but not in coverage
- A closure plan ordering the shortfalls, with retest needs called out early
Who uses the output
- Certification leads defending the verification set in review
- Verification engineers who close the coverage gaps and rerun what is needed
- Configuration managers reconciling status against the current baseline
How the work fits into the transaction or program
Verification traceability is where the requirements trace pays off or falls apart. This review confirms the evidence side after requirements traceability has confirmed the links, so the two together show requirements reached the design and were genuinely closed. It feeds the compliance map's evidence column and precedes the discipline-specific lifecycle-data reviews.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both look for real coverage rather than a bare link, and where the software or hardware assurance standards apply, the acceptable verification methods and independence expectations tighten with the level. The review measures coverage against the method expectations that apply to this article's assigned level rather than a flat standard.
Regulatory limits
This work checks whether verification evidence covers the requirements it is claimed against. It does not perform verification, does not make a compliance finding, and does not determine airworthiness or grant approval. Those remain with the applicant and the authority.
What this review does not cover
- Running or rerunning the tests, analyses, or inspections
- Writing the verification reports or closing deviations
- Making the compliance finding for verified requirements
Specific to this review
- Partial coverage is the most common way a verified requirement fails, because the evidence addresses the subject without addressing the whole requirement.
- A conditional pass is not verification until the condition is closed, yet it often carries as green in the matrix from the day the test ran.
- A single retest can reopen requirements that shared the test setup, so a late shortfall rarely costs only itself.
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 the requirements traceability review?
Requirements traceability confirms the links exist from requirement to design to verification. This review reads the verification evidence itself and confirms it actually closes the requirement, in full, with a result that holds. A clean link to weak evidence still leaves the requirement open.
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.