DO-178C compliance evidence is not produced only at the end of an avionics software project. It develops across planning, requirements, design, coding, verification, configuration management, and quality assurance activities.
This checklist identifies the principal evidence that should be created, reviewed, controlled, and traced throughout the software lifecycle. It is a working aid, not a substitute for the approved plans, applicable objectives, or agreement with the certification authority.
How to use this checklist
Applicability depends on the software level, the approved lifecycle and plans, the certification basis, and whether the project uses the DO-331, DO-332, or DO-333 supplements. Tool qualification considerations under DO-330 and supplier arrangements may add further evidence obligations.
1. Planning evidence
- Plan for Software Aspects of Certification (PSAC)
- Software Development Plan and Software Verification Plan
- Software Configuration Management Plan and Software Quality Assurance Plan
- Requirements, design, and coding standards
- Lifecycle environment, methods, and tool identification
- Tool qualification assessment and qualification plans where applicable
- Supplier-control approach where lifecycle data is externally produced
- Planning review records, findings, dispositions, and approvals
2. Software requirements evidence
- Software high-level requirements and associated attributes
- Traceability to system requirements and allocated safety requirements
- Derived-requirement identification, rationale, and feedback to system safety activities
- Interface definitions, data definitions, ranges, units, and timing constraints
- Evidence of accuracy, consistency, verifiability, and standards compliance reviews
- Requirements baseline, change history, review findings, and dispositions
3. Software design evidence
- Software architecture and low-level requirements
- Interface, data-flow, control-flow, and resource-use definitions
- Traceability from low-level requirements and architecture to high-level requirements
- Derived design requirements and associated rationale
- Design standards compliance and review evidence
- Controlled design baseline and approved change history
4. Source-code evidence
- Source code identified against the applicable software baseline
- Traceability from source code to low-level requirements
- Coding-standard compliance and deviation records
- Code review and static-analysis results
- Analysis of untraceable, deactivated, or unintended code
- Build environment, compiler options, generated code, and executable identification
5. Verification evidence
- Review procedures, checklists, results, and recorded dispositions
- Test cases, test procedures, test data, expected results, and actual results
- Requirements-based test coverage and traceability to verified requirements
- Normal-range and robustness testing evidence
- Structural coverage analysis, including MC/DC where applicable
- Data-coupling and control-coupling analysis
- Problem reports, corrective actions, regression tests, and closure evidence
- Verification independence records where required by the software level
6. Configuration-management evidence
- Configuration identification and controlled baseline records
- Problem report and change request authorization
- Impact analysis covering upstream and downstream lifecycle artifacts
- Configuration status accounting and change-history records
- Build, release, archive, retrieval, and reproducibility evidence
- Software conformity records and lifecycle environment versions
7. Quality-assurance evidence
- Process-compliance reviews and lifecycle-data conformity checks
- Records showing adherence to approved plans and standards
- Deviation, nonconformance, and corrective-action records
- SQA audit results, findings, dispositions, and approvals
- Evidence that transition criteria and completion criteria were satisfied
8. Certification and accomplishment evidence
- Software Configuration Index (SCI)
- Software Accomplishment Summary (SAS)
- Final traceability, requirements coverage, and structural coverage reports
- Open-problem assessment and operational-impact evaluation
- Compliance summaries and certification-authority review records
- Evidence packages supporting the applicable Stages of Involvement
Maintaining evidence as a digital thread
A checklist confirms that evidence exists. It does not prove that the evidence still agrees. The relationships between system requirements, software requirements, design, source code, verification cases, results, changes, and approvals must remain valid as the programme evolves.
For a focused comparison, see DO-178C traceability: spreadsheet versus a single digital thread.
How PES supports evidence continuity
Product Engine Suite (PES) is a Safety-Critical Software Engineering and Assurance Platform that connects requirements, design data, verification activities, reviews, PR/CR decisions, and controlled baselines. Evidence develops alongside engineering work instead of being reconstructed separately before an audit or certification review.
