Category: Uncategorized

You’ve decided to certify airborne software. You’ve heard the acronym: SOI. Someone told you there are “four audits” and your stomach dropped. Here is the plain-language version — what each review actually examines, why the schedule works in your favor, and how a small team walks through all four without drama.

What an SOI review is

DO-178C tells you what evidence a compliant software program must produce. It says nothing about when anyone looks at it. That gap is filled by the FAA’s Stage of Involvement (SOI) process (FAA Order 8110.49A and the FAA’s software review Job Aid): four reviews, each timed to when a chunk of your evidence should naturally exist.

• SOI 1 — Plans. Your five plans and three standards are written and under control. The question: if you execute this program as written, would it comply? Findings here are the cheapest you will ever get — each one is a mistake you now don’t have to build.
• SOI 2 — Development. Roughly half your requirements, design, and code exist, with at least one thread carried all the way down. Reviewers pull a requirement and follow it through design to code and back. They’re testing whether your data is one connected structure or separate plausible piles.
• SOI 3 — Verification. Half or more of testing is done, with results and initial coverage analysis. This is the longest look: test cases, robustness, structural-coverage gaps and how you dispositioned them.
• SOI 4 — Final. The final build: verification complete, configuration index exact, open problem reports justified, and your Accomplishment Summary answering the plan you filed at the start, deviation by deviation.

Why the four-stage rhythm protects small teams

Imagine one giant audit at the end instead. A systemic mistake — a broken traceability scheme, a misread coverage rule — would surface when it’s most expensive to fix. The SOI structure catches process errors while they are still process corrections, not product rework. For a small company, that timing difference is often the whole budget.

Two habits make the machinery work for you instead of against you:

• Close findings before the next stage leans on them. An unresolved SOI 1 finding at SOI 2 means the data being reviewed was produced by the defective process the finding already identified.
• Honor the entry criteria honestly. Showing up to SOI 3 with a third of testing done “to keep the schedule” buys you a partial review that must be repeated. Maturity criteria exist because reviewing immature data certifies nothing and costs everything.

And remember whose job is whose: you show compliance; the FAA (or its designee) finds it (14 CFR 21.20, 21.21(b)). The SOI reviews are simply the finder sampling your showing at four sensible moments. You don’t need to be an insider to pass them — you need discipline and complete evidence.

How to be ready for each stage

Use the SOIs as your own dashboard. Not “what percent complete are we,” but: which SOI could we pass today? That question is very hard to spin, which is exactly why it’s useful.

Practical readiness, stage by stage:

1. Before SOI 1 — plans consistent with each other, standards concrete enough that a reviewer could check code against them, software levels traceable to the system safety assessment, tool qualification needs named.
2. Before SOI 2 — pick three requirements yourself and walk each thread down to code and back. If you can’t navigate your own traceability, a reviewer can’t either.
3. Before SOI 3 — run your own coverage-gap review first: every gap dispositioned as dead code, deactivated code, or a requirements problem, in writing.
4. Before SOI 4 — the configuration index describes exactly the build being approved, and every open problem report has a written safety and functional impact assessment.

None of this requires a big company. It requires following the rules to the letter — which is precisely the discipline small teams can excel at.

---

Want the checklist version? Our free public-tier DO-178C checklists put these readiness questions in a form you can run against your own program — no cost, no strings: AeroCert Open Compliance Library on GitHub. For new-article alerts and webinar invites, join our mailing list on the Programs page, or write to info@aerocert.org.

AeroCert Institute Inc. is a 501(c)(3) nonprofit providing free, plain-language education on FAA regulations and aviation software safety.

DO-178C compliance is most efficient when assurance activities and evidence are built into software development—not reconstructed after the software is complete. When teams write code first and assemble certification data later, they may have to recover requirements, rebuild traceability, repeat verification under controlled conditions, and revisit design decisions. Under schedule pressure, that avoidable rework can become one of the program’s largest costs.

By AeroCert Institute — a federally recognized 501(c)(3) nonprofit organization founded by aviation safety professionals with FAA credentials. Reviewed July 2026.

There is a story that plays out repeatedly at small aerospace companies, and it usually begins with good news.

The prototype works. The demonstration went well. A customer—perhaps an airframer or systems integrator—is interested. Then comes the question that changes everything:

“What is your certification plan?”

For many teams, that is when DO-178C first becomes real—after key architecture, code, and test decisions have already been made.

What DO-178C Actually Requires

DO-178C, formally titled Software Considerations in Airborne Systems and Equipment Certification, is an industry consensus standard recognized by the FAA and other civil aviation authorities as an acceptable means of compliance for airborne software.

Its purpose is not to prescribe a programming language, coding style, or development methodology. Instead, DO-178C defines objectives for planning, software development, verification, configuration management, quality assurance, and certification liaison. The applicable objectives and level of rigor depend in part on the software level derived from the system safety assessment.

A Designated Engineering Representative (DER)—an individual authorized by the FAA to make certain findings of compliance on its behalf—may be among those reviewing the resulting life-cycle data.

Here is what often surprises newcomers: DO-178C says relatively little about how to write code. It focuses on what a program must be able to demonstrate about the way its software was planned, developed, verified, controlled, and documented.

The objectives are published. The process is not a secret.

But the framework works best when the software and its compliance evidence are developed together:

• Planning defines how the work will be performed and how compliance will be shown.
• Requirements are defined, reviewed, controlled, and linked to the software that implements them.
• Reviews and tests are traced to the requirements they verify.
• Results, baselines, problem reports, and approvals are retained under configuration control.

DO-178C does not require a waterfall development model. It does, however, require a disciplined and documented life cycle in which the required evidence can be reproduced and reviewed.

That is where a “move fast” prototype often diverges from certifiable software development.

Why Retrofitting Compliance Costs So Much

When the software already exists but the supporting life-cycle data does not, activities that should have occurred naturally during development may have to be performed in reverse.

Requirements must be recovered and validated

Instead of implementing approved requirements, the team must inspect the existing code and attempt to describe what it does.

That creates an immediate risk: a reverse-engineered requirement may merely restate the implementation rather than define the intended behavior, constraints, interfaces, and safety-related expectations. Each undocumented assumption becomes a decision that must be identified, evaluated, and justified.

Traceability must be rebuilt

The relationships among system requirements, software requirements, design, source code, verification cases, and verification results must be established.

Those relationships are relatively inexpensive to maintain while the work is being performed. Reconstructing them months or years later can require interviews, code analysis, document reviews, test analysis, and engineering judgment—often involving people who no longer remember why a decision was made or who are no longer with the company.

Verification may have to be repeated or expanded

Informal testing may have significant engineering value, but it may not be usable as certification evidence if the program cannot establish:

• The software version that was tested
• The test environment and configuration
• The test procedure and expected results
• The actual results and pass/fail criteria
• The review and approval status of the test data
• The relationship between each test and the requirement it verifies

In those cases, tests may need to be rewritten, reviewed, repeated, and documented against a controlled software baseline. Additional verification may also be necessary to satisfy requirements-based testing, robustness testing, structural coverage, independence, or other applicable objectives.

Design and implementation assumptions must be revisited

Decisions that were reasonable for a prototype may require additional controls, analysis, verification, or redesign before they are suitable for airborne software.

Examples include shared global data, undocumented timing assumptions, platform-specific behavior, implicit interface dependencies, incomplete error handling, or reliance on tools and libraries that were never evaluated in the certification context.

Late changes rarely remain isolated. A design change can affect requirements, source code, tests, traceability, coverage analysis, configuration records, and certification data.

Retrospective compliance work can uncover genuine defects and improve safety; it is not merely paperwork. But when the required evidence was not produced as part of the original life cycle, a substantial portion of the effort becomes avoidable rework.

That rework occurs on a product the team believed was nearly finished—often under schedule pressure, with a customer waiting. This is why “we will address compliance later” can become one of the most expensive decisions in the program.

Discipline Early Prevents Delay Later

Teams that reach certification with fewer surprises are not necessarily the teams with the largest budgets. They are usually the teams that treat assurance objectives as part of engineering from the beginning.

Understand the objectives before committing to flight software

The team does not need every answer before development begins. It does need to understand the likely software level, applicable objectives, expected life-cycle data, certification interfaces, and areas that could drive architecture or tool decisions.

Early coordination with the responsible certification authority or authorized representative can prevent major differences in interpretation later.

Create the plans early—and keep them aligned with the work

The Plan for Software Aspects of Certification, or PSAC, and its companion software plans describe how the program intends to satisfy the applicable objectives.

These plans should not become shelfware. The team must perform the work consistently with them. When the development or verification approach changes, the plans should be revised through a controlled process and coordinated as appropriate.

A mismatch between documented plans and actual practices can result in findings even when the underlying engineering approach is otherwise reasonable.

Maintain requirements and traceability continuously

Requirements should be reviewed, controlled, and linked to the design, code, and verification evidence throughout development.

Prototypes may help a team discover requirements, but certifiable software should not depend on undocumented behavior that can only be understood by reading the source code.

Capture evidence when the work is performed

Review records, analyses, test procedures, test results, traceability data, problem reports, and approvals are far less expensive to capture during the activity than to reconstruct later.

Contemporaneous evidence is also more reliable. It records what was reviewed, by whom, against which baseline, and with what result.

Establish configuration management early

The program should always be able to answer fundamental questions:

• Which version was reviewed?
• Which version was tested?
• Which requirements and test procedures applied to that version?
• Which problems were open or closed at the time?
• What changed between baselines?

Configuration management provides those answers. It also prevents teams from building certification conclusions on uncontrolled or mismatched data.

This discipline does not mean every artifact must be perfect before coding begins. Nor does it prohibit iterative or agile development. It means each iteration occurs within a defined, controlled, and reviewable life cycle.

Discipline beats heroics. When compliance activities are integrated into engineering, certification is no longer a wall at the end of the program. It becomes part of how the product was developed.

See What the Process Entails—Free

AeroCert publishes the Open Compliance Library: seven plain-language DO-178B/C checklists containing 88 checkpoints across:

• Software planning
• Requirements
• Design and source code
• Verification
• Configuration management
• Tool qualification
• The life cycle from the PSAC through the Software Accomplishment Summary, or SAS

The checklists provide a practical, high-level assessment of certification readiness. Teams can use them to identify questions and potential gaps before flight-software architecture, development processes, and delivery schedules are locked in.

They are free to use and share under the Creative Commons Attribution 4.0 license as part of AeroCert’s nonprofit mission to advance aviation safety for the public benefit.

Get the checklists at aerocert.org or access the library directly on GitHub.

Important Notice

AeroCert’s checklists are educational and compliance-support resources. They are not FAA-approved compliance data, do not replace DO-178C or applicable regulatory guidance, and do not guarantee a certification outcome.

The FAA does not issue a stand-alone DO-178C certificate for software. Software life-cycle data is evaluated as part of the applicable aircraft, product, or installation approval. Program-specific expectations depend on the certification basis, system safety assessment, software level, proposed means of compliance, approved plans, and coordination with the responsible certification authority or designee.