Accomplishment summary support for installation approval packages

When this review is needed

• A summary was written to declare the work complete and now has to be reconciled against the data it summarizes.
• Objectives were claimed satisfied before the last of the verification evidence was filed and linked.
• Anomalies were dispositioned during development and the summary needs to reflect their actual resolution.
• A reviewer is expected to read the summary first and sample from it, and the project wants its claims tested before that read.

The problem

An accomplishment summary is the document a reviewer reads first, and it is written to say the work is done. That framing is the problem: it is a set of claims, and claims are easy to make ahead of the evidence catching up. Objectives get declared satisfied while the verification record is still being filed, anomalies get summarized as resolved when their disposition is still open, and evidence references point at artifacts by a number that has since changed. The summary reads as closure while the data underneath it tells a slightly different story.

What gets reviewed

• Objective coverage the summary claims checked against the lifecycle and compliance data
• Anomalies recorded in the summary reconciled with their actual disposition
• Evidence references confirmed to point at the current artifact and revision
• Claims of completion tested for producible evidence rather than intent
• Consistency between the summary and the compliance matrix it accompanies
• A closure plan for claims the evidence does not yet support

What gets validated

• Each objective the summary declares satisfied resolves to a producible verification artifact
• Every anomaly the summary records matches its disposition in the underlying data
• Evidence references cite the current artifact number and revision, not a superseded one
• The summary's coverage claims agree with the compliance matrix in the same package
• No completion claim rests on work still in progress at the time of submittal

Evidence normally required

• The draft accomplishment summary and its evidence references
• The lifecycle and compliance data the summary claims to cover
• The anomaly or problem reports and their dispositions
• The compliance matrix the summary accompanies
• The verification records the summary asserts are complete

Common discrepancies

• An objective declared satisfied whose verification record cannot be produced
• An anomaly summarized as resolved while its disposition is still open in the data
• An evidence reference pointing at an artifact number that a revision has since changed
• A coverage claim in the summary that the compliance matrix does not support

What is at stake

A summary that overclaims is the fastest way to lose a reviewer's confidence, because it is the first thing read and the discrepancy between its claims and the data colors everything after. A single objective declared met without producible evidence invites the reviewer to distrust the rest and sample harder. Correcting the summary under review, while its overclaims are exposed, is far weaker than reconciling it to the evidence before anyone outside the project reads it.

How the work runs

What the buyer receives

• A claim-to-evidence reconciliation across the summary
• A gap assessment naming each claim the evidence does not support
• A closure plan to align the summary with its data before the package is submitted

Who uses the output

• Certification project managers confirming the summary will not overstate the package
• Engineering leads correcting claims that ran ahead of the evidence
• Compliance staff presenting a summary whose every claim can be produced

How the work fits into the transaction or program

The accomplishment summary sits at the top of the package and points down into the verification trace, the compliance matrix, and the lifecycle data. Reconciling it last, after those streams are settled, keeps the first document a reviewer reads from promising more than the evidence beneath it delivers. It is the final check that the package speaks with one voice.

Jurisdiction-specific considerations

FAA and EASA both expect a summarizing document that ties the compliance argument together, though its name and expected structure differ between the two systems. The reconciliation works to the summary the certification basis for this installation calls for, and it confirms the claims match the evidence regardless of which authority's format the summary follows.

Regulatory limits

The work reconciles the summary to the evidence it claims and flags overclaims. It does not perform the verification, does not make the completion determinations the summary asserts, and does not make a compliance finding or grant an approval. The compliance determination rests with the authority reading the package.

What this review does not cover

• Performing the verification the summary claims is complete
• Making the completion determinations on the authority's behalf
• Any compliance finding or approval based on the summary

Specific to this review

• The summary is read first, so an overclaim in it does more damage than the same gap buried in the lifecycle data, because it frames how the reviewer reads everything else.
• Evidence references age badly, since a summary written mid-project cites artifact numbers that later revisions quietly change underneath it.
• Anomaly dispositions are a frequent overclaim: the summary calls an item resolved while its problem report is still open in the data it points to.

Sources

Frequently asked questions

Relevant glossary terms

Related pages

Where this fits