Every DO-178C programme begins the same way: five plans and three standards, written before the interesting work starts, reviewed by people who were not in the room when they were written. It is tempting to treat them as an entry fee — documents to get past. That instinct is expensive.
The plans are where a programme commits to what it will do; everything afterwards is judged against them. This article walks through each document — what it is actually for, who reads it, and where SOI #1 reviews find the problems.
The set, and how it hangs together
The structural idea: the PSAC is written for the certification authority — a self-contained account of the system, the software level, the lifecycle, and how compliance will be shown. The four remaining plans are written for the team, in whatever depth the team needs, and the PSAC summarises and points to them. The three standards are the team's rulebooks, invoked by the plans and enforced by reviews.
The five plans, one at a time
| Plan | Primary reader | The question it must answer |
| PSAC — Plan for Software Aspects of Certification | The certification authority or its delegate | Is this a credible, complete route to compliance for software at this level? |
| SDP — Software Development Plan | The development team | How do requirements become design, code and integrated software — with which methods, environments and transition criteria? |
| SVP — Software Verification Plan | The verification team | How will reviews, analyses and tests satisfy the verification objectives — including independence and coverage resolution? |
| SCMP — Software Configuration Management Plan | Everyone, continuously | How are baselines, changes, problem reports and releases controlled — for evidence as well as code? |
| SQAP — Software Quality Assurance Plan | SQA, and the authority | How will conformance to all the other plans be independently assured, with records? |
Two of these deserve special comment because they are chronically underwritten.
The SCMP is not about code. It governs every lifecycle artifact — requirements, plans, test procedures, results, tool configurations. The single most common CM finding is a beautiful code baseline surrounded by uncontrolled evidence: requirements in a spreadsheet with no history, results in a folder named final_v2.
The SQAP is not a formality. SQA is the process's immune system — the function that audits whether the team is doing what the plans say, while there is still time to correct course. An SQAP that describes SQA as "reviewing documents" has already told the reviewer that quality assurance will be decorative.
Transition criteria: the load-bearing sentences
The three standards
| Standard | What it constrains | What good looks like |
| Requirements Standards | How requirements are written: notation, structure, identification, the attributes each must carry | Rules a reviewer can check mechanically — not aspirations like "requirements shall be clear" |
| Design Standards | Architecture and design constraints: notations, complexity limits, design patterns permitted and forbidden | Constraints traceable to real failure modes, not a style guide |
| Coding Standards | Language subset, constructs forbidden, naming, complexity thresholds | Often built on an industry subset — adopted deliberately, with each deviation justified |
The trap with standards is adopting more than you can enforce. Every rule in your coding standard is a promise that somebody — or some qualified tool — checks it. A 200-rule standard with no static analysis wired to it is 200 findings waiting for a reviewer with a sampling plan. Adopt what you will actually enforce, and justify the tailoring; a short standard honestly enforced beats a comprehensive one honoured in the breach.
Where SOI #1 actually finds problems
- The plans disagree with each other. The SVP promises independence the SDP's team structure cannot deliver; the PSAC names a tool the SDP never mentions. Reviewers read the set side by side precisely because authors rarely do.
- The plans disagree with reality. The SDP describes a process the team has never run — usually a template inherited from a different programme, with the previous project's assumptions still inside.
- Vague transition criteria. See above.
- Tool use without a qualification position. Every tool that eliminates, reduces or automates a process step needs a stated position — qualified, or its output independently verified. Silence here is a finding that compounds at SOI #3.
- The level's independence requirements not staffed. The plan says "with independence" where the objectives require it; the org chart makes it arithmetically impossible.
Writing them well, cheaply
The plans reward a specific discipline: write what you will do, then do what you wrote. The corollaries are practical. Write the plans with the people who will execute them, not for them. Keep the PSAC self-contained but thin — it summarises, it does not duplicate. Schedule a consistency pass across the set before anyone external sees it. And treat plan changes as normal: a plan revised under configuration management mid-programme is healthy; a plan that never changed while the programme did is the suspicious one.
Frequently asked questions
Can the plans be combined into fewer documents?
Yes — smaller programmes routinely combine them, and the standard's concern is that the planning information exists, is coherent and is followed, not the page count or binding. What does not shrink is the PSAC's role: the authority-facing account must still stand on its own.
Do the plans need authority approval before work starts?
The PSAC is submitted to the authority, and prudent programmes want its feedback before spending heavily against it — that is much of SOI #1's point. Starting development while the PSAC's fate is unknown is a schedule bet: sometimes reasonable, always worth making consciously.
Can we reuse plans from a previous programme?
As a starting structure, yes; verbatim, no. Reviewers recognise inherited plans instantly — the previous system's name in an unedited paragraph is a classic. Every reused sentence is still a commitment; make sure it is one this programme intends to keep.
Who should write the PSAC?
Someone who understands both the engineering and the certification conversation — it is a technical document with a diplomatic function. In practice it is often drafted by the certification liaison or a senior engineer and reviewed by everyone whose work it commits.
What changes in the plans at lower software levels?
The document set is the same; the commitments inside shrink with the objectives. A Level D SVP is short because Level D verification is short. The mistake is copying a Level A plan set for a Level D programme — you will be audited against everything you wrote, including the rigour you never needed to promise.
We write, review and repair certification plan sets — including the consistency pass that catches SOI #1 findings before the authority does. Get in touch.