STC accomplishment summary
STC program accomplishment summary evidence support
This review confirms that the accomplishment summary an STC submits is backed by the lifecycle data it claims. A certification engineer runs it as the package is finalized, once the software and hardware summaries are drafted. It reads the objective coverage, the anomalies and their disposition, and every evidence reference, then checks each claim against the records that are supposed to support it. You get a gap assessment on the summary, a trace map from each stated objective to its evidence, and a closure plan for the claims that outrun the data.
When this review is needed
- The lifecycle data is complete and the accomplishment summary has to be reconciled to it before submittal.
- Software and hardware summaries were written by different teams and have to present one consistent claim.
- Anomalies were dispositioned late and the summary has to reflect their actual resolution.
- The summary is the document an authority reads first and the program wants it audited against the evidence.
The problem
The accomplishment summary is the document that says the objectives were met, and it is often written before every last verification result is in hand, then not fully reconciled once they are. A summary that claims an objective satisfied when the record behind it proves a weaker result, or an anomaly described as resolved when its disposition is still open, reads as compliant while the data underneath does not support it. Because the summary is what the authority reads first, a claim that outruns the evidence sets the tone for the whole review.
What gets reviewed
- Objective coverage in the summary against the assigned software and hardware levels
- Each stated objective checked against the lifecycle record that satisfies it
- Anomalies and open problem reports against their recorded disposition
- Evidence references confirmed to point at data that exists in the package
- Consistency between the software and hardware summaries at the item boundary
- Deviations and their justification against the certification basis
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 the summary claims satisfied is supported by a lifecycle record that reaches it
- Anomalies described as resolved have a disposition that is actually closed
- Each evidence reference resolves to data present in the delivered package
- The claimed coverage matches the assigned level, not a lower one
- The software and hardware summaries agree where their evidence meets
Evidence normally required
- The draft software and hardware accomplishment summaries
- The lifecycle records the summary references
- The anomaly and problem-report log with dispositions
- The assigned software and design assurance levels
- The certification basis and any deviations claimed against it
Common discrepancies
- An objective claimed satisfied with a record behind it that proves less
- An anomaly described as resolved whose disposition is still open
- An evidence reference pointing at data the package does not contain
- Software and hardware summaries that disagree at the item boundary
What is at stake
A summary that overstates coverage draws findings the moment an authority checks a claim against its record, and it costs the program credibility on every other claim in the document. An anomaly recorded as closed but still open, or an objective asserted without evidence, forces the program to either produce the missing data under deadline or walk back the summary in front of the authority. Both are worse than reconciling the summary before it is submitted.
How the work runs
Read the claims
List every objective the summary states satisfied and every anomaly it reports resolved.
Check each against evidence
Confirm each claim is supported by a lifecycle record that actually reaches it.
Reconcile the seams
Check the software and hardware summaries agree where their evidence meets.
Close the overstatements
Plan the data or wording corrections for claims that outrun the record before submittal.
What the buyer receives
- A gap assessment on the summary against the lifecycle evidence
- A trace map from each stated objective to its supporting record
- A closure plan for the claims and anomalies that outrun the data
Who uses the output
- Certification leads confirming the summary is defensible before it is submitted
- Engineers reconciling software and hardware summaries into one claim
- Program managers who need the summary to match the evidence at submittal
How the work fits into the transaction or program
The accomplishment summary is the top of the evidence pyramid, the claim every lifecycle record is meant to support, so it is reconciled last, after the finding register and the underlying data are settled. This review confirms the summary matches what the package actually holds, so the first document the authority reads does not promise more than the evidence delivers.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA both read the accomplishment summary as the entry point to the software and hardware evidence, so where the STC is validated across both, the review notes where the summary has to be repackaged so each authority can follow its claims to the same underlying data.
Regulatory limits
The review reconciles the summary to the lifecycle evidence for consistency and support. It does not approve the summary, accept its claims as compliant, sign a compliance finding, or make an airworthiness determination on the modification.
What this review does not cover
- Producing the lifecycle evidence the summary references
- Dispositioning anomalies on the authority's behalf
- Signing the compliance findings the summary claims, or issuing the STC
Specific to this review
- The summary is usually written before the last verification results land, then not fully reconciled once they do, which is why a claim can outrun its record.
- Because it is read first, a single overstated claim in the summary undercuts the authority's confidence in every other claim in the document.
- Software and hardware summaries written by separate teams can disagree at the item boundary, and that seam is a frequent inconsistency the authority notices.
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. STC application process, certification basis, and continued airworthiness obligations of an STC holder.
European Union / EASA. EASA design and production certification, STCs, ETSO authorizations, and EASA Form 1 release.
RTCA. Environmental qualification test categories and procedures referenced by TSO and equipment qualification.
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
Frequently asked questions
Isn't the summary just a cover document over evidence we already reviewed?
It is the document the authority reads first, and its claims are what direct the review into the underlying data. A summary written before the last results landed can assert coverage the records do not yet support. Reconciling it after the evidence is complete keeps the first impression honest and protects the credibility of the whole package.
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.