Type-design data packages
Accomplishment summary support for a type-design data package
This review reads the accomplishment summary that certifies the software and hardware lifecycle results in a type-design data package, and tests whether its claims hold. A certification engineer checks that every objective the summary reports as satisfied points to lifecycle evidence that actually exists at the right assurance level, that open problem reports are disclosed rather than buried, and that anomalies carry a rationale the basis supports. It surfaces summaries that assert objectives met while the underlying records are thin or absent. You receive a gap assessment, an evidence map from each claim to its source data, and a closure plan you can work before submission.
When this review is needed
- An accomplishment summary is drafted and the team wants its objective claims verified before the authority reads it.
- Open problem reports exist at submission and the summary must state their status honestly.
- Multiple software and hardware items feed one summary and the assurance levels need to be reconciled.
- A supplier is delivering the summary to an integrator who will scrutinize every satisfied objective.
The problem
An accomplishment summary is written near the end of a program when schedule pressure is highest, and it is tempting to report an objective as met on the strength of an intended plan rather than the evidence in hand. Problem reports left open at the deadline get summarized softly, assurance levels get quoted from the plan instead of what the data supports, and the summary starts to describe the program the team meant to run rather than the one recorded in the lifecycle data.
What gets reviewed
- Each objective the summary reports satisfied checked against the lifecycle evidence behind it
- Assurance levels in the summary reconciled with what the data actually demonstrates
- Open problem reports confirmed disclosed with a status the basis will accept
- Anomalies and deviations tested for a documented, basis-consistent rationale
- Cross-references from the summary to plans, standards, and verification records validated
- Tool qualification claims checked where the summary relies on tool output
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 satisfied objective traces to lifecycle evidence at the claimed assurance level
- Open problem reports are listed with a disposition consistent with the certification basis
- The summary's assurance-level claims match the results the data supports, not the plan alone
- Each anomaly or deviation carries a rationale the basis permits
- References from the summary resolve to the actual plans, records, and reports they cite
Evidence normally required
- The draft accomplishment summary in its current revision
- The plans and standards the summary references, such as verification and configuration plans
- Verification results, review records, and the problem report log
- The assigned assurance levels and the safety assessment that set them
- Tool qualification data where summarized results depend on qualified tools
Common discrepancies
- Objectives reported satisfied whose lifecycle evidence is incomplete or not yet produced
- Open problem reports summarized without a disposition the basis accepts
- Assurance levels quoted from the plan that the delivered data does not support
- Anomalies noted without the substantiating rationale the certification basis requires
What is at stake
A summary the evidence cannot back is the fastest way to lose credibility with a certification office, because the reviewer samples claims against records and one unsupported objective invites a full re-examination. Discovering the gap after submission means reworking evidence under review scrutiny instead of on your own schedule, and open problem reports that were understated resurface as findings.
How the work runs
Map the claims
List every objective the summary reports satisfied and the assurance level it asserts for each.
Trace to evidence
Open the lifecycle data behind each claim and confirm it exists and matches the stated level.
Test the disclosures
Check that open problem reports and anomalies are disclosed with a basis-consistent disposition.
Deliver the punch list
Provide an evidence map and a closure plan for the claims and disclosures still unsupported.
What the buyer receives
- A gap assessment naming each summary claim the evidence does not yet support
- An evidence map linking every satisfied objective to its source lifecycle data
- A closure plan for the objectives, problem reports, and anomalies still open
Who uses the output
- Certification leads who sign and present the accomplishment summary
- Software and hardware leads confirming their objective claims are backed
- Integrators receiving the summary who will audit satisfied objectives
How the work fits into the transaction or program
The accomplishment summary is the top-level narrative a reviewer uses to sample the lifecycle data, so it is checked once the underlying evidence is largely in place. Verifying its claims early keeps the summary honest and gives the team a punch list before the certification office starts sampling.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
FAA and EASA accept accomplishment summaries built to the recognized software and hardware assurance guidance, but each phrases problem-report disposition and open-item handling in its own way. The review flags where a summary written for one authority needs its disclosures restated so an open item reads the same to the other.
Regulatory limits
This work evaluates whether the summary's claims are supported by the delivered lifecycle data. It does not produce a compliance finding, does not certify the software or hardware, and does not grant or transfer any approval.
What this review does not cover
- Producing the missing lifecycle evidence or closing open problem reports
- Performing the safety assessment that sets the assurance levels
- Qualifying development or verification tools on the supplier's behalf
Specific to this review
- An accomplishment summary is judged by its weakest claim, because reviewers sample rather than read every record, and one unsupported objective triggers wider scrutiny.
- Open problem reports are a disclosure test, not a defect count: understating them damages credibility more than the reports themselves.
- Assurance levels stated in a summary must match delivered data, not the plan, since plans routinely change during verification.
- When several items share one summary, mismatched assurance levels between them are a frequent source of confusion at review.
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 you help even if some verification is still running?
Yes. The review distinguishes objectives that are genuinely satisfied from those the summary reports optimistically, and it lists what each remaining objective needs. That lets you finish the open verification with a clear target instead of discovering the gap during formal review.
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.