Accomplishment-summary review for avionics and equipment suppliers

When this review is needed

• The program is closing and the summary is the last document the authority reads before deciding.
• Objective status in the summary was carried over from earlier drafts and may no longer match the closed evidence.
• Problem reports remain open and the team needs the summary to disclose them honestly without overstating their containment.
• Several deviations were agreed during the program and the summary has to record them accurately rather than quietly.

The problem

The accomplishment summary is the document a reviewer reads to decide whether to believe the rest of the package. It is also written under deadline, by people who want the program to look finished. Objective statuses get rounded up, open problem reports get understated, deviations get smoothed over, and the configuration the summary describes drifts from the one the evidence was built against. A summary that claims more than the evidence holds is the fastest way to lose a reviewer's trust in the whole submission.

What gets reviewed

• The summary read against the certification plan and sub-plans it answers
• The objective status the summary claims against the evidence that supports it
• Whether the summary discloses its open problem reports and their containment
• How the summary represents deviations recorded against the basis
• The configuration the summary describes against the configuration index
• Consistency between the summary's claims and the compliance data behind them

What gets validated

• The summary addresses each commitment the certification plan made
• Claimed objective status agrees with the evidence and the compliance checklist
• Open problem reports are disclosed with an honest account of their containment
• Agreed deviations are recorded accurately rather than omitted or softened
• The configuration the summary cites matches the configuration index
• The summary's claims are consistent with the compliance matrix and lifecycle data
• Residual open items are stated rather than implied to be closed

Evidence normally required

• The draft accomplishment summary, software or hardware as applicable
• The certification plan and sub-plans the summary answers
• The compliance checklist and matrix the summary draws its status from
• The open problem report log and the deviation records
• The configuration index for the build the summary describes

Common discrepancies

• Objective status in the summary that the underlying evidence does not support
• Open problem reports understated or absent from the summary's disclosure
• Agreed deviations that were never recorded in the summary
• A configuration cited in the summary that the configuration index contradicts
• Summary claims that disagree with the compliance checklist or matrix
• Residual open items written as if they were closed

What is at stake

A summary that overstates closure invites the reviewer to test the gap between what it claims and what the evidence shows, and a single overstated claim casts doubt on the rest. The schedule cost is the re-examination; the larger cost is that the summary, the one document meant to vouch for the program, becomes the reason the program is doubted.

How the work runs

What the buyer receives

• An assessment of whether the summary matches the program's real state
• A list of claims that overstate, omit, or contradict the evidence
• A reconciliation of the summary against the plan, checklist, and configuration index
• A prioritized correction list ordered by the trust each gap puts at risk

Who uses the output

• Certification leads finalizing the closing summary
• Engineering teams correcting the claims the review flagged
• Program management confirming the summary is submission-ready

How the work fits into the transaction or program

The review closes the loop a certification-plan review opens: the plan promised, the summary reports, and this check confirms the two agree against the evidence. It draws on the compliance-checklist and configuration data, so it pairs naturally with reviews of those once the summary points back to them.

Jurisdiction-specific considerations

FAA and EASA both expect a closing summary that ties the program back to its plan, and the RTCA and EUROCAE structure is largely common. The difference is whether the summary is read by an authority engineer, a delegate, or a design organization's own oversight, so the review checks the summary's claims against the evidence regardless of who will read it next.

Regulatory limits

Endeavor Elements checks the applicant's accomplishment summary for completeness, consistency, and traceability to the evidence. It does not make compliance findings, accept the summary on the authority's behalf, or issue any approval. The applicant and the authority keep their roles.

What this review does not cover

• Accepting the summary or making official compliance findings
• Issuing any approval or authorization
• Writing the accomplishment summary on the supplier's behalf

Specific to this review

• The accomplishment summary is the document reviewers use to calibrate trust, so an overstatement here costs more credibility than the same gap buried in the lifecycle data.
• Honest disclosure of open problem reports survives review better than a clean-looking summary the evidence later contradicts.
• A summary written from earlier drafts can claim a status the evidence has since moved past, so the most common finding is a stale claim rather than a false one.
• The summary is the only place the plan and the delivered evidence are meant to meet, which is why a plan-to-summary mismatch surfaces gaps that neither document shows alone.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits