PMA article data
Verification traceability support for a PMA article approval package
This review examines the verification traceability in a PMA article approval package, from each requirement to the test, analysis, inspection, or review that proves it. A certification engineer confirms every requirement marked verified actually points to evidence that covers it under the right conditions, and that the verification method suits what the requirement demands. It catches requirements shown complete with no verification evidence behind them. You receive a gap assessment, a requirement-to-verification map, and a closure plan before the package enters formal review.
When this review is needed
- Verification is wrapping up and the team wants coverage confirmed before the package is declared complete.
- Some requirements read verified but the linked evidence has not been checked against them.
- Verification methods were mixed across test, analysis, inspection, and review and coverage must reconcile.
- A requirement changed after verification ran and its evidence may no longer cover the new intent.
The problem
Verification status is a status column, and status columns get ahead of evidence. A requirement gets marked verified when a test passes, but the test covered a subset of the conditions, or an analysis was planned and never issued, or a review closed a requirement without a record. Method also matters and gets glossed: a requirement that needs test is marked satisfied by inspection, and the status reads complete while the evidence does not actually demonstrate what the requirement demands.
What gets reviewed
- Each requirement marked verified traced to the evidence that verifies it
- Verification method checked against what each requirement actually demands
- Evidence confirmed to cover the requirement's full conditions, not a subset
- Requirements shown complete with no verification record flagged as open
- Verification affected by a requirement change re-checked for continued coverage
- Multi-method verifications reconciled so combined evidence covers the requirement
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 requirement marked verified links to evidence that exists and covers it
- The verification method matches what the requirement requires to be shown
- Evidence covers the full range of conditions the requirement specifies
- Requirements changed after verification retain evidence that still applies
- Where methods combine, the total evidence closes the requirement
Evidence normally required
- The verification traceability data at its current state
- Test reports, analyses, inspection records, and review minutes
- The requirements set the verification is claimed against
- The verification plan defining method per requirement
- The change history for requirements verified before a late change
Common discrepancies
- Requirements marked verified with no test, analysis, or review record attached
- Evidence covering only part of the conditions a requirement specifies
- A requirement verified by a method weaker than the requirement demands
- Verification left stale by a requirement change that ran after the test
What is at stake
A verification claim without evidence is the single item a reviewer is most likely to sample, and a miss there suggests every other verified requirement deserves the same scrutiny. Coverage gaps found in formal review force re-testing or re-analysis under the reviewer's timeline, and a requirement verified by the wrong method may have to be re-verified entirely, which can pull in a test article that is no longer configured.
How the work runs
List the verified set
Pull every requirement marked verified and the method and evidence claimed for each.
Test coverage
Open each evidence item and confirm it exists, uses the right method, and covers the full conditions.
Check for staleness
Compare requirement change dates against verification dates and flag any coverage a change invalidated.
Deliver the map and plan
Provide a requirement-to-verification map and a closure plan for open and re-verification items.
What the buyer receives
- A gap assessment listing each verified requirement lacking sufficient evidence
- A requirement-to-verification map showing method and coverage per requirement
- A closure plan for the open verifications and the re-verifications needed
Who uses the output
- Certification leads asserting verification completeness at review
- Quality leads confirming verification records exist and cover their requirements
- Verification engineers running the closing tests and analyses
How the work fits into the transaction or program
Verification traceability closes the loop the requirements trace opens: it proves the implemented requirements were actually shown met. It is checked as verification completes so coverage gaps surface while test articles and setups still exist, rather than during a review that would force a costly reconstitution.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
This work supports PMA approval under the FAA framework, and where software or hardware is involved verification follows the recognized development assurance guidance. The review keeps the coverage argument in FAA terms and does not restate it for another authority.
Regulatory limits
This review assesses whether verification evidence covers the requirements marked complete. It does not perform verification, does not make a compliance finding, and does not grant PMA or any airworthiness approval.
What this review does not cover
- Running the tests, analyses, or inspections that close open verifications
- Authoring or changing the requirements being verified
- Configuring or maintaining the test articles and setups
Specific to this review
- Verification coverage most often fails on conditions: a test passes but exercises a subset of the range the requirement specifies.
- Method substitution is a quiet defect; a requirement that needs test but is closed by inspection reads complete while proving less.
- A late requirement change can invalidate verification that already passed, so change dates must be compared against verification dates.
- Re-verification is the costliest finding here because it can require a test article that has since been reconfigured or released.
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.
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
What happens if a requirement was verified by the wrong method?
The review flags it as needing re-verification and identifies the method the requirement actually demands. The concern is that inspection or analysis sometimes substitutes for test where test is required, so the status reads complete while the evidence proves less than the requirement asks. Catching it before review lets you re-verify while the setup still exists.
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.