Accomplishment summary support for ETSO authorization

When this review is needed

• The lifecycle data is complete and the summary claims objective coverage that a reviewer will want to trace to source.
• Unresolved problem reports exist at the assurance level and the summary has to disclose them with their disposition.
• The claimed DAL does not obviously match the depth of the lifecycle evidence assembled behind it.
• The summary was written from a plan rather than from the delivered evidence and may claim more than the data shows.

The problem

An accomplishment summary is often drafted from the assurance plan, describing what was supposed to happen, and then not fully reconciled to what the delivered lifecycle data actually contains. Objectives get marked satisfied because the process called for them, not because the reviewer can point to the review record, the test result, or the analysis that satisfies them. Problem reports still awaiting disposition get summarized as resolved, and the assurance-level claim carries assumptions that the evidence underneath never fully backed.

What gets reviewed

• Each objective claimed satisfied linked to the specific lifecycle artifact that satisfies it
• Open problem reports and anomalies disclosed with their disposition and any deferred rationale
• The claimed design assurance level checked against the depth and independence of the delivered evidence
• Software DO-178C and hardware DO-254 lifecycle references reconciled to the actual data set
• Summary claims about tool qualification and derived requirements traced to their supporting records
• Consistency between the summary, the plans it derives from, and the evidence it points to

What gets validated

• Every objective marked satisfied cites a lifecycle artifact a reviewer can retrieve and read
• Problem reports still open appear in the summary with a stated disposition rather than being omitted
• The evidence depth and independence support the design assurance level the summary claims
• DO-254 hardware lifecycle references resolve to actual data, not to plan sections
• Derived requirements and tool qualification claims trace to the records that back them

Evidence normally required

• The draft accomplishment summary and its objective-coverage claims
• The DO-178C software lifecycle data set: plans, reviews, tests, and analyses
• The DO-254 hardware lifecycle data where the article contains complex hardware
• The open and closed problem report log at the assurance level
• Tool qualification and derived-requirement records referenced by the summary

Common discrepancies

• An objective claimed satisfied with no lifecycle artifact behind the claim
• An open problem report summarized as resolved when its disposition is still pending
• A claimed assurance level that the delivered evidence does not support at the required independence
• A DO-254 reference that points to a plan section rather than to delivered hardware data

What is at stake

A summary that claims coverage the lifecycle data cannot show turns the authority's review into a hunt for evidence that may not exist, and every objective that fails to trace becomes a finding against the assurance case. If the claimed DAL outruns the depth of the delivered data, the shortfall is not a paperwork fix: it can mean additional verification activity at the claimed level, which reopens work the supplier considered finished.

How the work runs

What the buyer receives

• A gap assessment of objectives claimed satisfied without a traceable lifecycle artifact
• An evidence map from each summary claim to its lifecycle source
• A closure plan for the objectives and problem reports the summary overstates

Who uses the output

• Certification leads confirming the summary will survive the authority's trace to evidence
• Assurance engineers reconciling objective claims against the delivered lifecycle data
• Quality staff verifying that disclosed problem reports carry an honest disposition

How the work fits into the transaction or program

The accomplishment summary is the document a reviewer reads first and uses to decide where to probe, so it functions as the index into the whole assurance case. This review runs after the lifecycle data is complete and before the summary is submitted, so the gap between what the summary claims and what the evidence shows is closed by the supplier rather than exposed by the authority sampling behind a claim.

Jurisdiction-specific considerations

Under the EASA route, the accomplishment summary supports the applicant's declaration that the assurance objectives are met, and the authority relies on it being an accurate index into evidence it can sample at will. Where the same software and hardware is used toward an FAA TSO, the review notes where a summary written to one authority's expectations for objective phrasing and independence needs adjustment for the other.

Regulatory limits

The review checks that the summary's claims trace to lifecycle evidence and disclose open items honestly. It does not perform the assurance activities, assign or approve a design assurance level, grant the ETSO authorization, or commit the authority to accept the assurance case.

What this review does not cover

• Performing DO-178C or DO-254 verification activities to fill a coverage gap
• Assigning or approving the design assurance level
• Any authority acceptance of the summary or the assurance case

Specific to this review

• The summary is frequently written from the assurance plan rather than the delivered data, so it describes intended coverage instead of demonstrated coverage.
• A claimed DAL that outruns the delivered evidence is a substantive gap, because closing it can require added verification at the claimed level rather than a documentation edit.
• Undisclosed open problem reports are the summary's most damaging omission, since the authority tends to find them and then distrusts every other claim in the document.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits