Accomplishment summary
Accomplishment summary support for a major change
This review checks that the accomplishment summary for a major change claims only what the underlying lifecycle evidence actually supports. A certification engineer runs it before the summary is submitted as the top-level statement of compliance. It confirms that every objective the summary reports as met references real lifecycle data, that open problem reports and anomalies are dispositioned rather than glossed, and that the DO-178C and DO-254 evidence stands behind each claim. You receive a gap assessment flagging objectives asserted beyond their evidence, an evidence map from summary claim to source data, and a plan for the claims that need shoring up.
When this review is needed
- The accomplishment summary is drafted and its objective claims have not been checked against the lifecycle data.
- Problem reports were still open when the summary was written and their disposition is not clear in it.
- The summary reports objectives met at the target assurance level but the evidence sits at a lower one.
- A reviewer will read the summary first and cross-check its claims into the DO-178C and DO-254 data.
The problem
An accomplishment summary is written to declare compliance, so it tends toward the optimistic. Objectives get reported as met while a portion of the supporting evidence is still in work, open problem reports are summarized as if resolved, and the assurance level claimed can outrun what the lifecycle data demonstrates. The summary reads clean on its own, and the gap only appears when someone traces a claim back into the software and hardware data behind it.
What gets reviewed
- Each objective the summary claims met traced to the lifecycle evidence supporting it
- Open problem reports and anomalies dispositioned rather than reported as resolved
- The assurance level claimed matched to what the DO-178C and DO-254 data demonstrates
- Software and hardware lifecycle data references verified as resolving to real artifacts
- Deviations and open items carried transparently rather than absorbed into a met claim
- Summary claims mapped against the certification basis for the change
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 objective reported met references lifecycle evidence that actually demonstrates it
- Open problem reports are dispositioned with a rationale rather than summarized as closed
- The assurance level the summary claims is supported by the underlying data at that level
- Each lifecycle data reference in the summary resolves to a real artifact in the package
- Deviations and limitations are stated in the summary rather than hidden inside a met objective
Evidence normally required
- The draft accomplishment summary for the change
- The DO-178C and DO-254 lifecycle data supporting the objective claims
- The open problem report log and its dispositions
- The certification plan defining the target assurance levels
- The certification basis for the change
Common discrepancies
- An objective reported met while part of its supporting evidence is still in work
- An open problem report summarized as resolved without a disposition rationale
- A claimed assurance level that the lifecycle data supports only at a lower level
- A lifecycle data reference in the summary that does not resolve to an artifact
What is at stake
A summary that claims more than the evidence supports is the fastest way to lose a reviewer's confidence, because the summary is the document they read first and check against the data. An objective asserted met without sufficient evidence reopens as a finding, an undispositioned anomaly becomes an action item, and the credibility of the whole submission suffers once one claim is shown to outrun its proof.
How the work runs
Trace each claim
Confirm every objective the summary reports met references lifecycle evidence that demonstrates it.
Disposition the anomalies
Check open problem reports carry a disposition rationale rather than a resolved label.
Check the assurance level
Confirm the claimed assurance level is supported by the underlying data at that level.
Plan the closure
Sequence the fixes so the summary claims only what the evidence proves before submission.
What the buyer receives
- A gap assessment flagging objectives asserted beyond the evidence behind them
- An evidence map from each summary claim to the source lifecycle data
- A closure plan for the claims and dispositions that need shoring up before submission
Who uses the output
- Certification engineers ensuring the summary claims only what the data proves
- Software and hardware leads confirming lifecycle evidence stands behind each objective
- Compliance managers reconciling the summary against the open problem report log
How the work fits into the transaction or program
The accomplishment summary is the capstone a reviewer reads before diving into the data, so this review confirms its claims match the lifecycle evidence before it is submitted. It draws on the DO-178C and DO-254 data and the problem report log, and any claim it flags feeds the finding register as an item to close rather than a surprise for the authority to find.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
The FAA and EASA both accept an accomplishment summary as a top-level compliance statement, but the level of detail each expects and how open problem reports are presented can differ. The review notes where a summary sufficient for one authority needs additional disposition detail for the other.
Regulatory limits
The review confirms the summary's claims are supported by the lifecycle evidence. It does not accept the summary on the authority's behalf, grant credit for an objective, or make any airworthiness determination.
What this review does not cover
- Writing the accomplishment summary from scratch
- Accepting an objective as met on the authority's behalf
- Producing the lifecycle evidence a claim depends on
Specific to this review
- The summary is written to declare compliance, so its natural bias is optimistic, which is exactly why its claims have to be checked against the data rather than read at face value.
- An open problem report summarized as resolved is a common trap, because a disposition rationale is what makes it acceptable and prose alone hides its absence.
- A claimed assurance level that outruns the lifecycle data is subtle: the objective may genuinely be met, just not to the level the summary asserts, which a reviewer catches on cross-check.
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.
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
Can the summary carry open problem reports, or do they all have to be closed?
Open problem reports can remain, but each has to be dispositioned with a rationale showing why it does not affect the compliance claimed. The problem is a report summarized as resolved when it is not, because a reviewer cross-checks the summary against the problem report log and reopens the difference.
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.