Pre-submittal review
Closing unsupported compliance claims before a certification submittal
An unsupported-claims closure pass reads your certification package the way a project engineer will and stops at every assertion of compliance that no document behind it actually proves. It runs before submittal, once the package is drafted but before it reaches the authority, and it is done for the applicant's certification team. Each unsupported claim is either tied to real evidence already in hand, matched to evidence you can still retrieve, or restated honestly as an open item with an owner. You get a closure brief, an evidence request list, and a disposition package a reviewer can work through without sending it back.
When this review is needed
- A dry run of the package showed compliance statements that point to nothing when you follow the reference.
- The compliance matrix marks a requirement satisfied but the cited report covers a different configuration or a superseded revision.
- A first submittal already came back with a request for the data behind a claim you thought was closed.
- Leadership wants the package audited for empty assertions before it reaches the authority and consumes a review cycle.
The problem
A package can read as complete and still rest on claims nobody can substantiate. A statement says a requirement is met and cites an analysis, but the analysis addresses an earlier design, or the reference resolves to a document that was never issued. Under schedule pressure the team writes the compliance narrative faster than the evidence catches up, and the gaps hide inside language that sounds finished.
What gets reviewed
- Every compliance statement in the package traced to the specific document meant to prove it
- Citations checked so the referenced report matches the claimed requirement and the current configuration
- Claims that cite a superseded, draft, or never-issued document flagged for correction
- Assertions with no locatable evidence separated from those where evidence exists but was not cited
- Each unsupported claim dispositioned as closeable, retrievable, or genuinely open with an owner
- The compliance narrative rewritten so no sentence claims more than the evidence delivers
What gets validated
- Each cited reference opens to a document that exists and carries the revision the claim relies on
- The evidence behind a claim addresses the same requirement and hardware or software standard the claim names
- Analyses and test reports cover the configuration as submitted, not an interim design that has since changed
- Requirements marked satisfied in the matrix have a live pointer to substantiating data, not a placeholder
- Restated open items carry a named owner and a path to the missing evidence rather than softened wording
Evidence normally required
- The drafted certification evidence package as it stands before submittal
- The compliance matrix or checklist linking requirements to their cited evidence
- The document register or data index the citations are supposed to resolve against
- Analysis reports, test results, and substantiation data referenced by the claims
- The certification plan and any acceptable means of compliance agreed with the authority
Common discrepancies
- Compliance statements that cite an analysis written against a design revision the program has since moved past
- Requirements marked met in the matrix whose referenced document was planned but never released
- Claims where the evidence exists in the data set but the citation points at the wrong report
- Narrative language that implies substantiation the underlying data does not actually contain
What is at stake
A reviewer who finds one hollow claim starts distrusting the rest, and the whole package slows while every citation is re-checked. Each unsupported assertion that survives to the authority becomes a written request for information, and those requests arrive weeks apart, turning one avoidable gap into repeated review cycles the program cannot get back.
Move from findings to resolution
Identify the missing data behind the finding.
How the work runs
Walk every claim to its evidence
Follow each compliance statement to the document it cites and confirm the document exists at the revision the claim depends on.
Separate hollow from mispointed
Split claims with no locatable evidence from claims whose evidence exists but is cited wrong, since they close by different routes.
Disposition each gap
Mark every unsupported claim closeable now, retrievable with a named request, or genuinely open with an owner and a path.
Assemble the reviewer package
Deliver corrected claims tied to reachable evidence and a brief a project engineer can move through without returning it.
What the buyer receives
- A closure brief listing every unsupported claim with its disposition and the reasoning behind it
- An evidence request list naming the documents needed to substantiate or retire each claim
- A reviewer-ready disposition package that ties each corrected claim to the evidence a project engineer can open
- A marked-up compliance narrative with unsupported assertions corrected or restated as open
Who uses the output
- Certification engineers who have to defend each claim in front of the authority
- Program managers deciding whether the package is ready to submit or needs another pass
- Compliance-matrix owners closing out requirements with evidence that will hold up
How the work fits into the transaction or program
This pass sits between package assembly and formal submittal. The compliance matrix says what should be proved; this work confirms that the proof is real and reachable before a reviewer discovers it is not. What it leaves behind feeds directly into the disposition record the authority works from and into the finding register that tracks anything still open.
Start with a single asset
Confirm each requirement maps to substantiating evidence.
Jurisdiction-specific considerations
Whether the package goes to the FAA under 14 CFR Part 21 or to EASA under Regulation 748/2012, the failure mode is the same: an assertion of compliance the reviewer cannot follow to evidence. The closure pass reads to the agreed certification basis and the acceptable means of compliance for the program, so a claim is judged against the standard actually in force rather than a generic checklist.
Regulatory limits
This work checks whether claims are substantiated by the evidence on hand and organizes them for review. It does not make findings of compliance, issue or grant any approval, and does not decide airworthiness. Those determinations belong to the authority and its delegated engineers.
What this review does not cover
- Generating the missing analysis or test evidence that a claim requires
- Making compliance findings or issuing any approval on the authority's behalf
- Redesign of the product to make a stalled claim closeable
Specific to this review
- An unsupported claim is more expensive than a blank one, because a blank draws a question while a false-confident claim draws distrust of the entire package.
- The most common hidden failure is a citation that resolves to real data written against a design the program has since revised, so the reference looks valid until you read the configuration line.
- Restating a claim as open before submittal costs one honest sentence; letting the authority find it costs a review cycle and the credibility of the citations around it.
- Evidence often already exists for a claim flagged as unsupported; the defect is a mispointed citation, not missing data, and that is the cheapest class of finding to close.
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.
Frequently asked questions
How is an unsupported claim different from a plain gap in the package?
A gap is a place where the package says nothing and everyone can see the requirement is unaddressed. An unsupported claim says the requirement is met and points at evidence that turns out to be missing, wrong, or written against an old design. Gaps invite a question; unsupported claims invite a reviewer to doubt the citations you got right, which is the more damaging outcome.
Can you close every unsupported claim before we submit?
Not always, and pretending otherwise is the problem being fixed. Some claims close immediately once the correct citation is attached, some close after a named document is retrieved, and a few stay genuinely open. Those last ones are restated honestly with an owner so the authority sees a tracked item rather than a false assertion.
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.