Field approval, accomplishment summary
Field-approval accomplishment summary support
This support confirms that the accomplishment summary presented for a field approval is backed by the lifecycle evidence it claims. It reconciles the summary's statements of objective coverage, its open-problem and anomaly disposition, and its evidence references against the underlying software and hardware data. An engineer who reads accomplishment summaries for a living runs it before submission. What you get is a gap assessment marking where the summary claims more than the evidence shows, a trace from each claim to its source artifact, and a plan to bring the overstated items back into line.
When this review is needed
- A software or hardware accomplishment summary is the headline document a reviewer reads first.
- The summary states all objectives were met but the coverage was never checked against the data.
- Open problem reports are dispositioned in the summary and those dispositions need to hold up.
- A returned package cited a summary that overstated coverage the lifecycle data did not carry.
The problem
The accomplishment summary is the document a reviewer opens first, and it is written to say objectives were met. That framing invites a gap between what the summary claims and what the lifecycle data actually shows, especially where objectives were partially met or closed by disposition. A reviewer who spot-checks a claim against the data and finds it unsupported stops trusting the summary, which turns a headline document into a liability.
What gets reviewed
- Objective coverage claims reconciled to the software and hardware lifecycle evidence
- Open-problem and anomaly dispositions checked against the level and DAL that constrain them
- Evidence references in the summary confirmed to point at data the package contains
- Deviations and their justifications against the certification basis
- Consistency between the summary and the configuration index it describes
- Any objective closed by analysis rather than test, with the analysis available
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
- Each objective the summary claims met is supported by evidence the package actually holds
- Anomaly and open-problem dispositions are consistent with the assigned software level or DAL
- Every evidence reference in the summary resolves to a real artifact in the data
- Deviations are justified against the certification basis rather than asserted
- The summary describes the same configuration as the index it accompanies
Evidence normally required
- The software or hardware accomplishment summary
- The lifecycle evidence and verification results it references
- The open-problem and anomaly reports with their dispositions
- The configuration index for the software or hardware items
- The assigned software level or DAL and the certification basis
Common discrepancies
- An objective claimed met where the evidence shows only partial coverage
- An anomaly dispositioned in a way the assigned level does not permit
- An evidence reference that points at an artifact the package does not contain
- A deviation stated without a justification against the certification basis
What is at stake
A summary that claims coverage the evidence does not carry gets the whole package read with suspicion, and the reviewer traces every claim rather than relying on the summary as intended. That turns a document meant to speed the review into one that slows it, and overstated claims usually resolve into real lifecycle work that should have been done before submission.
How the work runs
Read the claims
List the objective coverage and disposition claims the summary makes about the lifecycle data.
Reconcile to evidence
Check each claim against the software or hardware evidence the package actually holds.
Test the dispositions
Confirm anomaly and open-problem dispositions are consistent with the assigned level or DAL.
Close the overstatements
Sequence the claims the evidence does not support so the summary is honest before submission.
What the buyer receives
- A gap assessment where the summary claims more than the evidence supports
- An evidence map from each summary claim to its source artifact
- A closure plan for the overstated or unsupported claims
Who uses the output
- Engineering leads reconciling the summary to what the lifecycle data actually shows
- Compliance managers submitting a summary a reviewer can trust on its face
- Maintenance leadership relying on a coverage claim backed by real evidence
How the work fits into the transaction or program
The accomplishment summary is the top of the evidence pyramid, so this review sits above the software, hardware, and finding work and checks that the headline claims rest on what those reviews confirmed. Getting the summary honest before submission preserves its purpose of speeding the reviewer's read instead of inviting a line-by-line trace.
Start with a single asset
Reduce finding cycles by checking the package first.
Regulatory limits
The review reconciles the accomplishment summary to its supporting evidence and reports the overstatements. It does not accept the summary, make a compliance finding, approve the lifecycle data, or determine airworthiness. Those decisions rest with the FAA.
What this review does not cover
- Producing the lifecycle evidence a summary claim depends on
- Accepting the summary or its dispositions on the FAA's behalf
- An airworthiness ruling on the equipment the summary covers
Specific to this review
- The accomplishment summary is read first, so an unsupported claim in it colors how the reviewer treats the whole package.
- Objectives closed by analysis rather than test need the analysis on hand, or the claim reads as unsupported.
- A single evidence reference that resolves to nothing can shift the reviewer from trusting the summary to tracing every line.
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.
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 does this differ from reviewing the lifecycle data itself?
The lifecycle review checks whether the underlying evidence reaches the assigned level. This review checks whether the accomplishment summary honestly describes that evidence. A summary can overstate coverage even when much of the data is sound, and it is the first thing the reviewer reads.
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.