TSO authorization
Accomplishment summary support for a TSO authorization
This review readies the accomplishment summaries that close out the software and complex-hardware lifecycles behind a TSO article, so the claim that objectives were met is backed by the evidence the lifecycle produced. It is run for an equipment or avionics supplier before the authorization package is presented. The work checks objective coverage at the article's assurance level, confirms that open problem reports are dispositioned rather than hidden, and verifies that each lifecycle data reference the summary cites actually resolves. You receive a gap assessment against the planned objectives, an evidence map from summary to lifecycle data, and a closure plan for the objectives claimed but not yet substantiated.
When this review is needed
- The software and hardware lifecycles are wrapping up and the summaries have to demonstrate the objectives were met.
- The article's DAL was set high enough that objective coverage will be examined line by line.
- Open problem reports remain and their disposition has to be reflected honestly in the summary.
- The summary cites lifecycle data by identifier and each reference has to resolve to a controlled record.
The problem
An accomplishment summary is written to declare that a lifecycle is complete, which pulls it toward asserting more coverage than the underlying data yet supports. Objectives get marked satisfied on the strength of a plan rather than a result, problem reports still open at write time get summarized as trending toward closure, and lifecycle references point to data identifiers that were renumbered or never finalized. The summary reads as a finished argument while the evidence beneath parts of it is still moving.
What gets reviewed
- Objective coverage checked against the planned set for the article's assurance level
- Each satisfied-objective claim traced to the lifecycle result that supports it, not the plan
- Open problem reports confirmed as dispositioned with their effect on the summary stated plainly
- Lifecycle data references resolved to controlled, retrievable records
- Any deviation from the plans reflected in the summary rather than left unstated
- Objectives claimed without sufficient evidence collected into a closure plan
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 points to a lifecycle result that actually demonstrates it
- Open problem reports are listed with a disposition, not folded into a general completeness claim
- Each lifecycle data reference in the summary resolves to a controlled document under configuration management
- Objective coverage matches the assurance level the article's function requires
- Deviations from the approved plans are reflected in the summary rather than silently omitted
Evidence normally required
- The draft software and hardware accomplishment summaries
- The approved lifecycle plans defining the objective set and assurance level
- The lifecycle data the summaries reference, under configuration control
- The open and closed problem report list with dispositions
- The certification basis establishing the applicable objectives
Common discrepancies
- An objective marked satisfied against a plan commitment rather than a completed lifecycle result
- An open problem report summarized as trending closed with no disposition recorded
- A lifecycle data reference pointing to an identifier that was renumbered or never finalized
- Objective coverage stated at a lower rigor than the article's assurance level requires
What is at stake
A summary that overstates objective coverage does not survive a detailed read: the authority follows a claimed objective to its evidence, finds the evidence thin, and the article's assurance argument weakens at exactly the level where it is examined hardest. Open problem reports presented as nearly closed can mask a real defect, and unresolved lifecycle references turn a review into a document hunt that stalls the schedule.
How the work runs
Set the objective baseline
Establish the planned objective set for the article's assurance level from the approved lifecycle plans.
Trace claims to results
Confirm each satisfied-objective claim rests on a completed lifecycle result rather than a plan commitment.
Surface the problem reports
Confirm open problem reports are listed with a disposition and their effect on the summary is stated.
Plan the shortfalls
Collect unsupported objectives and undispositioned reports into a closure plan with owners.
What the buyer receives
- A gap assessment separating substantiated objectives from those claimed without sufficient evidence
- An evidence map from each summary claim to the lifecycle data that supports it
- A closure plan for the unsupported objectives and undispositioned problem reports
Who uses the output
- Certification engineers finalizing the summaries for the data package
- Software and hardware leads accountable for the lifecycle evidence behind each claim
- Program managers confirming the assurance argument is complete before review
How the work fits into the transaction or program
The accomplishment summaries are the top of the software and hardware assurance arguments, so this review runs once the lifecycles are close enough to closure that the claims can be tested against real data. It draws on the same lifecycle evidence the finding register and compliance argument use, and its closure plan defines the objective and problem-report work that must land before the package reaches the authority.
Start with a single asset
Reduce finding cycles by checking the package first.
Jurisdiction-specific considerations
Under the FAA framework the summaries are read against the objectives the article's assurance level requires, so the review sizes objective coverage to that DAL rather than to a lighter internal completeness check that would not hold at authority review.
Regulatory limits
The review reconciles the summaries to the lifecycle evidence and confirms objective coverage can be shown. It does not accept the assurance argument, determine that an objective is satisfied on the authority's behalf, or grant the authorization.
What this review does not cover
- Performing the lifecycle activities or generating the missing objective evidence
- Dispositioning open problem reports on the design's behalf
- Any authority acceptance of the summaries or the article
Specific to this review
- A summary is written to declare completion, which biases it toward claiming coverage the lifecycle data has not yet finished demonstrating.
- Open problem reports are the item most often softened in a summary, because listing them with a disposition looks worse than a general completeness claim even though the disposition is what the authority wants.
- Objective coverage must match the article's DAL, so a summary written to a lighter internal standard can pass an in-house check and still fail 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).
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).
RTCA. Design assurance objectives and lifecycle data for airborne electronic hardware (FPGA/ASIC/PLD).
Frequently asked questions
What is the most common overstatement in an accomplishment summary?
Claiming an objective is satisfied on the strength of the plan that intended to satisfy it, rather than the completed result that actually did. A reviewer follows the claim to its lifecycle data, and if the data shows the activity was planned but not finished, the objective reopens.
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.