Certification problem
Requirements marked met without verification evidence behind them
This page is for avionics and equipment suppliers whose compliance matrix shows requirements as met while the verification record behind the claim is missing. It triggers when an internal read or an authority comment questions how a met status was substantiated. The review walks each met requirement back to its verification method and the record that closes it, examining test reports, analyses, inspection records, and review minutes. You get a list of requirements whose met status has no supporting evidence and the artifact each one still needs.
When this review is needed
- An internal review questions how a met requirement was actually closed and no record can be produced.
- Verification was planned by analysis or inspection but the analysis note or inspection record was never filed.
- A late requirement change left earlier verification stale and the met status was never re-substantiated.
- The team wants each met claim tied to a record before the package leaves for review.
The problem
A met status is a claim, and the claim only holds if a verification record stands behind it. Matrices accumulate met marks during development faster than the supporting test reports, analyses, and inspection records get filed. By submittal the status column reads complete while a fraction of the entries have no artifact a reviewer can open. A reviewer who asks to see the record for a met requirement and gets nothing has found the gap before you did.
What gets reviewed
- Each requirement carrying a met status in the compliance matrix
- The verification method assigned to that requirement, by test, analysis, inspection, or review
- The specific record that is supposed to close each met requirement
- Whether the cited record actually demonstrates the requirement rather than an adjacent one
- Requirements verified by analysis whose analysis note was never produced or filed
- Met statuses that predate a requirement change and were never re-confirmed
What gets validated
- Every requirement marked met names a verification method and points to a closing record
- The closing record exists, is retrievable, and addresses the requirement it is attached to
- Test-verified requirements reference a test case and a result, not just a procedure
- Analysis-verified requirements have a written analysis with a stated conclusion
- Inspection-verified requirements carry a dated inspection record naming the article
- No met status survives only as a checkbox with nothing behind it
Evidence normally required
- The compliance matrix or requirements set with current verification statuses
- The verification method assigned to each requirement
- Test reports, analysis notes, inspection records, and review minutes assembled so far
- Any change history that moved a requirement after it was first verified
Common discrepancies
- A met status whose only backing is the word met, with no record attached
- An analysis-verified requirement where the analysis was discussed but never written down
- A test-verified requirement pointing to a procedure with no recorded result
- A record attached to the wrong requirement, demonstrating a neighboring claim
- Verification that was valid before a requirement edit and was never refreshed afterward
What is at stake
An unsubstantiated met status reads as a closed item until someone asks for proof, and then it reopens as an action. Each unsupported claim turns into a request for evidence, the program assembles it late under pressure, and the review that should have closed extends while the missing artifacts are produced.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
List the met claims
Pull every requirement carrying a met status and the verification method assigned to it.
Open the records
Retrieve the record behind each met status and confirm it exists and addresses that requirement.
Mark the gaps
Flag met statuses with no record, with the wrong record, or with verification stale after a change.
Order the closure
Name the artifact each gap needs and sequence the work toward submittal.
What the buyer receives
- A list of met requirements with no retrievable verification record
- For each gap, the verification method expected and the artifact that would close it
- A short note where an attached record demonstrates a different requirement than claimed
- A closure order weighted toward the entries a reviewer is most likely to probe
Who uses the output
- Verification leads producing the missing records
- Certification engineers correcting the matrix entries
- Program management sequencing the closure work before submittal
How the work fits into the transaction or program
This is a focused pass on one failure mode, the met status with nothing behind it. It runs as part of a wider evidence review when a program needs the qualification, software, and hardware data examined as well.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Regulatory limits
Endeavor Elements checks whether the applicant's met statuses are backed by retrievable records. It does not make compliance findings for the authority, accept the verification on the authority's behalf, or guarantee that a met status will be accepted.
What this review does not cover
- Performing the missing tests, analyses, or inspections
- Issuing any approval or making official compliance findings
- Authoring the verification records the program still owes
Specific to this review
- A met status is a claim about a record, so a met entry with no retrievable artifact is unsubstantiated regardless of how the engineering went.
- Analysis and inspection verification leave the thinnest paper trail, so they are where unwritten records cluster.
- Requirement edits made after verification silently invalidate the earlier met status unless the verification is explicitly refreshed.
- An attached record can be present and still fail the check if it demonstrates a different requirement than the one it is filed against.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
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).
SAE International. Development assurance process at aircraft and system level, including requirements capture and validation.
Frequently asked questions
Is a verification procedure enough to support a met status?
No. A procedure describes how verification would be done. A met status needs the executed result, the written analysis, or the dated inspection record that actually closes the requirement.
Do you produce the missing verification records?
No. The review identifies which met requirements have no record and names the artifact each one needs. The supplier's verification team produces the records.
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.
Walk through your situation with an engineer who has done this work.