Nothing on a first DO-178C programme produces more anxiety per unit of information than the words the authority will be conducting a review. Teams imagine an exam. What actually happens is closer to a structured sampling of evidence you are supposed to already have — and once you understand what is sampled and why, the reviews become schedulable engineering events rather than looming judgement.

Here is what each Stage of Involvement examines, what reviewers actually do in the room, and what reliably goes wrong.

What SOI reviews are for

The certification authority — or, far more often, its delegate — cannot read every artifact a programme produces, and does not try. Stage of Involvement reviews exist so that problems are found while they are still cheap: a bad plan is corrected at SOI #1 for the cost of an edit, and at SOI #4 for the cost of a schedule slip. The four stages are pinned to the lifecycle points where each class of problem first becomes visible.

The four Stage of Involvement audit points positioned against the lifecycle stages they review SOI 1 Planning SOI 2 Development SOI 3 Verification SOI 4 Certification readiness Certification audit points
Four scheduled engagements, each pinned to the point where its class of problem first becomes visible.

Two facts that defuse most of the anxiety. First, the schedule is proposed by you, in the PSAC — these are not surprise inspections. Second, the depth of authority involvement is scaled to the programme: software level, novelty, and your track record all affect how much attention you get. A first-time applicant at Level A should expect more presence than a veteran at Level C.

The four stages, one by one

Stage When Evidence on the table The real question
SOI #1 — Planning Plans approved, before heavy development PSAC, SDP, SVP, SCMP, SQAP, the three standards Is this plan credible, complete, and matched to the software level?
SOI #2 — Development A meaningful body of requirements, design and code exists Requirements, design data, code, traceability, reviews done so far Are you actually following your own plans and standards?
SOI #3 — Verification Verification substantially complete Test cases and procedures, results, coverage analyses, problem reports Is the verification evidence complete, and does it genuinely close?
SOI #4 — Final Before approval SAS, SCI, open problem reports, final CM records Is this software ready, and are the remaining known problems acceptable?
What each Stage of Involvement review examines, and the question actually being asked.

What reviewers actually do: the thread pull

Reviewers sample. The canonical move — worth rehearsing before every SOI #2 and #3 — is the thread pull: pick one requirement, more or less at random, and follow it down through design to code to the test case that exercises it and the result that shows it passed. Then back up the other way: pick a piece of code and ask which requirement asked for it.

How an SOI reviewer samples: most requirements are left unsampled, one is selected, and the reviewer follows that single requirement's thread down through design, code, a test case and its test result, then back up to the requirement — a break anywhere in the thread becomes a finding Requirements 1 2 3 4 5 Design Code Test case Test result One requirement, traced end to end A break anywhere in the thread becomes a finding
The thread pull. One requirement followed down to code, test and result — and a break anywhere along it becomes a finding.

The logic of sampling is what makes it powerful: the reviewer did not pick that requirement because it was special. If the thread breaks, the working assumption is that other threads are broken too, and the sample widens. This is why traceability debt is so expensive at review time — a single broken link doesn't cost you one finding, it costs you the reviewer's confidence in the whole matrix.

Findings, observations, and what happens next

Review outcomes are recorded at different severities — broadly, issues that must be resolved and tracked to closure, and lower-grade observations worth fixing but not gating. Neither is a verdict on the programme; both are ordinary outputs of a working review. What actually damages a programme is not receiving findings, it is receiving the same finding twice — nothing erodes an authority's confidence faster than closure that didn't hold.

What reliably goes wrong

  1. SOI #1 held too late. The plans get approved after the work they govern is half done, and every deviation becomes retroactive.
  2. The traceability matrix built for the review. Reviewers can tell when trace links were bulk-created the month before; the thread pull finds the seams within the first hour.
  3. Derived requirements with no safety feedback. A classic SOI #2 finding, and a completely avoidable one.
  4. Coverage analysis that stops at the number. "95% achieved" without an account of the other 5% — dead code, deactivated code, or a test gap — is not an analysis, it is a measurement.
  5. Problem reports triaged optimistically. At SOI #4 the open problem list is read carefully. A report classified as no-safety-effect with a one-line justification invites exactly the scrutiny it was hoping to avoid.
  6. Presenting evidence nobody in the room can navigate. If the person answering questions cannot find the artifact under discussion in under a minute, the review slows, and slow reviews go badly.

Preparing without theatre

The preparation that works is unglamorous: run your own thread pulls before the reviewer does. Pick ten requirements across the levels, follow each all the way down and back, and fix what breaks. Do the same backwards from code. Read the open problem list the way a sceptic would. Then brief whoever will be in the room on where things are, including the weak spots — reviewers respond far better to "we know about this and here is the plan" than to discovering it themselves.

None of this is specific to any one authority. The mechanics of engagement differ between the FAA, TCCA and EASA — who conducts the review, under what delegation — but the evidence being sampled and the thread-pull logic are the same everywhere.

Frequently asked questions

Are SOI reviews mandatory?

The stages are the standard shape of authority engagement on a DO-178C programme, but the depth and formality are scaled to the software level, the novelty of the product, and the applicant's history. The schedule is proposed in your PSAC and agreed with the authority or its delegate.

Who actually conducts the review?

Very often a delegate rather than the authority itself — a DER on US programmes, a DAR or DAO in Canada, organisational privileges in Europe. The delegation model changes the working relationship but not the evidence being examined.

How long does an SOI review take?

Typically on the order of days, not weeks, per stage — but the calendar cost is dominated by preparation and by closing whatever is found, not by the review itself. Budget for the closure, not just the meeting.

What happens if we fail one?

"Fail" is the wrong frame. Reviews produce findings, findings get closure plans, and the programme continues. The genuinely bad outcomes are findings that reopen after being closed, and systemic findings — where one broken thread widens into doubt about the whole evidence set.

Can SOI reviews be done remotely?

Frequently, especially for planning-stage reviews, and desk reviews of submitted data are common. Expect at least some on-site or hands-on engagement at the later stages, where the reviewer wants to drive the evidence themselves. The mix is agreed case by case.

Preparing for a first SOI review — or holding a finding you'd like a second opinion on before you respond? Get in touch.