Field approval data
Verification traceability support for an FAA field approval
This review checks the verification traceability in a field-approval package, confirming that each requirement marked complete is backed by the test, analysis, inspection, or review evidence that actually verifies it. It is run by or for a modifier or operator once verification is under way or wrapping up, before the package is presented to an inspector. It looks for requirements shown complete with no verification result behind them, verification methods claimed but not matched to the requirement's actual character, and results that verify an earlier configuration than the one being approved. You get a gap assessment, an evidence map from each requirement to its verification result, and a closure plan for the requirements that read as verified but are not.
When this review is needed
- Testing and analysis are finishing and each requirement marked complete needs the result that closes it attached.
- A verification method was claimed for a requirement it does not actually suit, such as review where test was needed.
- Configuration changed after a test and the result now verifies a build that is not the one being approved.
- Software or hardware verification against DO-178C or DO-254 has to tie into the package's overall trace.
The problem
Status advances faster than the evidence that should back it. A requirement gets marked verified when a test is scheduled, when an analysis is drafted, or when a review is planned, and the status holds even though the closing result has not landed. Method mismatch compounds it: a requirement that needs a test gets closed by an inspection or a review because that was quicker, and the trace records a method the requirement's character does not actually support. Underneath both, configuration moves, and a result run against an earlier build keeps verifying a requirement whose implementation has since changed.
What gets reviewed
- Each requirement marked complete matched to the verification result that closes it
- Each method checked against the character of the requirement it claims to verify
- Results confirmed to verify the configuration being approved, not a superseded build
- Test, analysis, inspection, and review evidence each traced to a retrievable source
- DO-178C and DO-254 verification results tied into the package's overall verification trace
- Environmental verification against DO-160G matched to the requirement and the installation
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 cites a retrievable test, analysis, inspection, or review result
- The verification method matches the requirement's character rather than the quickest available method
- Each result was produced against the configuration being approved, not an earlier one
- Software and hardware verification results connect into the package's overall trace
- Environmental verification categories match the requirement and the installation environment
Evidence normally required
- The requirement set with each requirement's verification status
- The verification results: test reports, analyses, inspection records, and review records
- The configuration each result was produced against
- Any DO-178C or DO-254 verification data for embedded software or hardware
- The installation and environmental definition for environmental verification
Common discrepancies
- A requirement marked verified whose cited result was never produced
- A requirement closed by review or inspection where its character required a test
- A verification result run against a configuration the alteration has since changed
- A software verification result not connected into the package's overall trace
What is at stake
A requirement marked verified without a result is an evidence gap that an inspector finds by pulling the reference and getting nothing, which casts doubt across the rest of the trace. A method mismatch is subtler and worse: the requirement looks closed but is not actually demonstrated to the depth it needs, so the alteration's compliance rests on verification that would not hold if examined. A result against a stale configuration verifies the wrong thing entirely, leaving the approved build unverified while the trace claims otherwise.
How the work runs
Match results to requirements
Confirm every requirement marked verified cites a retrievable result that closes it.
Test the methods
Check each verification method against the character of the requirement it claims to satisfy.
Confirm the configuration
Verify each result was produced against the configuration being approved, not an earlier build.
Close the gaps
List requirements with missing, mismatched, or stale verification and sequence the fixes before submission.
What the buyer receives
- A gap assessment of requirements marked verified without a result behind them
- An evidence map from each requirement to its verification result
- A closure plan for the requirements whose verification is missing, mismatched, or stale
Who uses the output
- Engineering leads confirming every completed requirement has a real verification result
- Compliance staff checking that verification methods suit the requirements they close
- Maintenance leadership confirming results verify the configuration actually being approved
How the work fits into the transaction or program
Verification traceability is the last check between requirements and the inspector, the point where each requirement either has its result or is exposed as merely marked complete. This review runs as verification finishes and before submission, so requirements without results, method mismatches, and stale-configuration results are caught while the team can still re-run or re-cite, rather than when an inspector pulls a reference and finds nothing behind it.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
An FAA inspector reviewing field-approval data samples the verification behind the requirements, and where the alteration contains software or complex hardware the DO-178C and DO-254 verification expectations apply within the field-approval package. The review flags where verification assembled for a field approval would need to deepen for an STC on the same modification, since the type-certificate route probes the verification evidence more thoroughly.
Regulatory limits
The review checks that verification evidence exists, suits each requirement, and reflects the approved configuration. It does not perform the verification, re-run tests, obtain the field approval, or determine that the altered aircraft is airworthy.
What this review does not cover
- Performing the test, analysis, inspection, or review that closes a requirement
- Re-running verification against the current configuration
- Any airworthiness determination on the altered aircraft
Specific to this review
- Verification status runs ahead of evidence because a requirement gets marked verified when a test is scheduled, not when the result lands.
- A method mismatch is more dangerous than a missing result, because the requirement looks closed while being demonstrated to less depth than its character requires.
- A result run before a configuration change verifies a build that is no longer being approved, so the trace can be full while the approved configuration is unverified.
Sources
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
U.S. Government (eCFR). Maintenance recordkeeping content and approval-for-return-to-service requirements, including 43.9, 43.11, and Appendix B.
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).
Frequently asked questions
Is a requirement verified if the trace says complete but the method was wrong?
No. A requirement closed by review or inspection when its character required a test is not demonstrated to the depth it needs, even though the status reads complete. The review checks the method against the requirement, not just that some method was recorded, because a mismatch leaves the compliance resting on verification that would not hold under examination.
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.