Pre-submittal finding closure
Closing requirements marked complete without verification evidence
This work catches requirements that a project reports as verified while no test, analysis, inspection, or review evidence actually stands behind them. An engineer reads the requirements and verification trace, isolates each requirement whose verification status is asserted but unsupported, and connects it to the real evidence or names what is missing. It runs during a pre-submittal review, before the package reaches the authority. You receive a closure brief listing the unsupported requirements, an evidence request list for the artifacts still owed, and a disposition package that shows each requirement tied to verification a reviewer will accept.
When this review is needed
- A pre-submittal pass shows requirements marked verified but the linked artifact is empty, missing, or points nowhere.
- A verification method was planned as test but closed on the strength of an analysis that was never written.
- Requirements were declared complete under schedule pressure and the evidence was expected to catch up but did not.
- A tool migration or trace-tool change dropped the links between requirements and their verification records.
The problem
A verification matrix that reads green is not the same as a verified design. Requirements get flipped to complete on the expectation that the report is coming, links break when data moves between tools, and a method planned as test quietly closes on an analysis nobody produced. By submittal the team believes it is done, but a reviewer who pulls three requirements at random and finds no evidence behind them will assume the rest are no better, and the whole package loses credibility.
What gets reviewed
- Each requirement whose verification status is asserted checked for a real, retrievable artifact
- Verification method reconciled to the evidence type actually produced
- Broken or dangling trace links between requirements and their verification records identified
- Requirements closed on planned-but-unwritten analysis flagged as evidence owed
- The distinction between a missing link and missing evidence stated for each finding
- A corrected trace showing each requirement mapped to verification a reviewer can open
What gets validated
- Every requirement marked verified resolves to an artifact that exists and can be retrieved from the data set
- The verification method recorded matches the kind of evidence the linked artifact actually contains
- No requirement closes on an analysis, test, or inspection that has no corresponding report
- Trace links survive the move between the requirements tool and the verification records
- Where evidence is genuinely absent, the requirement is flagged as owed rather than left showing complete
Evidence normally required
- The requirements database or matrix with verification status
- The verification trace linking requirements to test, analysis, inspection, and review artifacts
- The available verification reports, test results, and analysis records
- The verification plan defining the intended method per requirement
- The reviewer's or internal finding describing the unsupported entries
Common discrepancies
- A requirement marked verified whose linked report was never delivered
- A verification planned as test but closed on an analysis that does not exist
- Trace links severed by a tool migration, leaving requirements pointing at nothing
- A single report cited against several requirements it does not actually cover
What is at stake
Unsupported verification is the fastest way to draw a systemic finding. Rather than one requirement, the reviewer questions the integrity of the entire trace, and closing that costs far more than the original gap. If the evidence genuinely does not exist, the verification work itself has to be scheduled, which is a program hit that lands worst when it is discovered at the authority instead of in-house.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Sample and confirm
Pull the requirements marked verified and check that each links to a retrievable artifact.
Separate link from evidence
Distinguish requirements that are merely unlinked from those with no evidence at all.
Reconnect or flag
Restore trace to existing evidence, and flag the genuinely missing reports as owed.
Package the disposition
Write the closure brief, list the outstanding artifacts, and show each requirement tied to verification.
What the buyer receives
- A closure brief listing each requirement lacking verification evidence and its resolution
- An evidence request list for the reports and analyses still owed
- A reviewer-ready disposition package showing each requirement tied to real verification
Who uses the output
- Certification engineers correcting the trace before the package is submitted
- Program managers deciding whether outstanding verification fits the schedule or moves it
- Verification leads confirming which artifacts are truly missing versus merely unlinked
How the work fits into the transaction or program
This closure runs late in a pre-submittal review, once requirements and verification are supposed to be linked. It sits between the raw trace and the compliance argument built on it, because a compliance matrix cannot honestly cite verification that is not there. Closing it cleanly protects the credibility of every downstream claim in the submittal.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
FAA and EASA both expect verification evidence to stand behind a verified requirement, but they differ in how much of the trace they will sample and what they accept as an equivalent method, so the corrected trace is presented in the form the reviewing authority works from.
Regulatory limits
This work locates unsupported verification and maps requirements to existing evidence. It does not perform the verification, write the missing test or analysis reports, approve the trace, or make any compliance finding, which remain with the applicant and the authority.
What this review does not cover
- Executing test, analysis, or inspection to generate the missing evidence
- Authoring the verification reports that are owed
- Making the compliance finding on any requirement
Specific to this review
- Unsupported verification tends to trigger a systemic finding rather than a point finding, because a reviewer extrapolates from the samples that fail.
- The riskiest case is a method downgraded from test to analysis without the analysis existing, since the status looks closed but rests on nothing.
- Tool migrations routinely sever verification links while leaving the status field intact, so the trace reads complete while the evidence is orphaned.
Sources
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
How do you tell a broken link from missing evidence?
We search the verification data set for the artifact a requirement should reference. If it exists, the fix is to restore the link. If no report exists anywhere, the requirement is flagged as owed so the program can schedule the verification, rather than leaving it showing complete.
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.