Software closure evidence
Software Accomplishment Summary (SAS) review
A Software Accomplishment Summary review checks that an article's SAS closes the loop the plan opened: that what the program says it accomplished matches the commitments in the PSAC, the objectives for the assigned software level, and the configuration the data was produced against. It is used by avionics and equipment suppliers at the end of a software program. You receive a reviewed SAS and a list of the claims that are unsupported, open against plan, or inconsistent with the lifecycle data behind them.
When this review is needed
- A software program is closing and the summary has to demonstrate that the plan was followed end to end.
- Open problem reports remain and the summary has to state honestly which are deferred and why.
- The build configuration changed late and the summary has to reflect the version the data actually covers.
- A supplier wants the closure record read independently before it is bound into the submittal.
The problem
The SAS is read as the proof that the plan was honored, but it is usually written under schedule pressure at the moment everyone wants the program finished. Claims get rounded up: objectives are reported as satisfied when the supporting data is one revision behind, and open problem reports are summarized in a way that softens what is still unresolved. Those gaps are exactly what a reviewer probes.
What gets reviewed
- Each accomplishment claim and the lifecycle data that substantiates it
- Consistency between the SAS and the commitments made in the PSAC
- Coverage of the DO-178C objectives for the assigned software level
- Open problem reports, deferred items, and the disposition stated for each
- The software configuration and version the summary reports against
- Recorded deviations from the plan and whether each carries a rationale
What gets validated
- Every objective reported as satisfied is backed by lifecycle data that currently exists
- Each commitment in the PSAC is addressed by a corresponding statement in the SAS
- Open and deferred problem reports are disclosed with their disposition and rationale
- The configuration the summary cites matches the build the evidence was produced from
- Any deviation from the plan is recorded rather than quietly dropped
- The software level reported in the summary matches the level the plan committed to
Evidence normally required
- The current Software Accomplishment Summary draft
- The agreed PSAC and companion software plans
- The verification results and the problem report register
- The software configuration index for the reported build
Common discrepancies
- Objectives reported satisfied where the cited data is a revision behind the build
- PSAC commitments that the summary never returns to
- Unresolved problem reports understated or absent from the disposition list
- A configuration reference that does not match the verified build
- Plan deviations resolved in practice but never recorded in the summary
What is at stake
A summary that overstates completion invites the authority to ask for the data behind each claim, and the data that does not exist or does not match becomes a finding at the worst possible point in the schedule. The closure that was meant to end the program reopens it.
Move from findings to resolution
Identify gaps against the means of compliance.
How the work runs
Answer the plan
Walk each PSAC commitment and confirm the summary returns a corresponding statement for it.
Substantiate the claims
Check that every objective reported satisfied is backed by lifecycle data that currently exists at the cited revision.
Reconcile the build
Confirm the configuration the summary cites matches the build the verification evidence was produced from.
Flag and reconcile
Return the reviewed summary with unsupported claims flagged and a note tying it back to the plan.
What the buyer receives
- A reviewed SAS with each claim confirmed or flagged
- A list of accomplishment statements that are unsupported or inconsistent with the data
- A reconciliation note tying the summary back to the plan commitments it answers
Who uses the output
- Certification leads binding the closure record into the submittal
- Software engineering leads producing the data behind flagged claims
- Program management deciding whether the program can close
How the work fits into the transaction or program
The review closes the bracket a PSAC review opens, checking the summary against the plan the program agreed to and the build the data was produced from. It feeds a fuller certification data package when the software evidence sits inside an equipment-level submittal.
Start with a single asset
Confirm requirements trace through verification.
Regulatory limits
The review checks the applicant's summary against its own plan and data. It does not make compliance findings, accept the closure on the authority's behalf, or guarantee that the authority will agree the objectives are satisfied.
What this review does not cover
- Accepting the closure or making findings on the authority's behalf
- Producing the lifecycle data behind an unsupported claim
- Dispositioning open problem reports on the program's behalf
Specific to this review
- The SAS is judged against the PSAC; a summary that does not answer every plan commitment leaves the program open against its own terms.
- Closure pressure makes rounded-up completion claims the most common SAS finding, not technical gaps in the software itself.
- A configuration mismatch between the summary and the verified build undercuts every objective the summary reports.
- Deferred problem reports are scrutinized for disposition and rationale, because a summary that softens what remains open is the easiest place for a reviewer to start.
Sources
RTCA. Objectives and lifecycle data for airborne software assurance, by design assurance level (DAL A-E).
U.S. Government (eCFR). Type certificates, STCs (Subpart E), TSO authorizations (Subpart O), PMA (Subpart K), and export airworthiness approvals (Subpart L).
SAE International. Safety assessment methods (FHA, PSSA, SSA, FTA, FMEA) supporting development assurance level assignment.
Frequently asked questions
How is this different from a PSAC review?
A PSAC review checks the plan before the program runs. The summary review checks, at closure, whether the program delivered what that plan committed to and whether the data exists to back each claim.
Can you review a summary that still has open problem reports?
Yes. The review checks that open and deferred problem reports are disclosed with their disposition and rationale rather than softened, which is a frequent finding at closure.
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.
Walk through your situation with an engineer who has done this work.