What Happens When the FAA Looks at Your Software? SOI Reviews, Explained

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.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *