Topic · DO-333

What is DO-333, and how do I keep formal analysis true in CI?

Gist

DO-333 is the formal methods supplement to DO-178C. FM.1 and FM.2 ask whether the high-level and low-level shalls are even implementable. Proof runs that check with Kind2 via proof realize, then fails the merge when the graph is stale.

proof realize specs/system ./... --diagnose

Keep SPARK or Frama-C if you need FM.3 on source. Keep VectorCAST or LDRA if you need a DO-330 qualified C toolchain. Proof is not that qualification.

Request demo Suite green vs Kind2

01 · Credit that does not re-run

A solver log from last PSAC is not this push.

DO-333 lets formal analysis satisfy some DO-178C objectives. A person can paste the log once. The next commit does not reopen Kind2.

The four jobs that are not the supplement (checkable shalls, re-derived links, MC/DC, a named reviewer) live on the DO-178C-style page. A Z3 lemma on one Go function lives on Z3 / Kind2. This page is the supplement: run the HLR/LLR analysis on the shalls you actually wrote, every merge.

FM.1 is formal analysis of high-level requirements. FM.2 is the same at low-level. Kind2 realizability asks whether an implementation can exist. Pairwise consistency asks whether two shalls contradict. Vacuity flags a shall that is true because the trigger never fires. Z3 data lemmas ask a property for every input, not the three the suite sampled. None of that is FM.3. FM.3 is source code. SPARK and Frama-C keep that row.

proof validate --preflight
proof realize specs/system ./... --diagnose
proof audit --fail-level warn

The first command rejects a sentence the 288 templates cannot parse. The second is Kind2 on the loaded spec. The third is the standing gate. A green suite is not this check. Tests sample. Realizability does not.

02 · The exhibit

Same shalls. A sample, or every input Kind2 can see.

The suite still has the three cases. The formula moved. Click the tabs.

go test

Cases the three the author typed
HLR-04 still in the comment

Sampled

This push

The shall changed. Kind2 did not run.

No re-solve

go test

Still three cases. Still a sample.

Keep the suite

Proof

Ask is this set of shalls realizable
Gate audit --fail-level warn

Merge blocked if Kind2 says no

Same shalls. A sample, or every input Kind2 can see. Click the tabs.

Who	What they notice	What they lose
DO-333 / RTCA	The supplement, FM.1 through FM.5, credit toward DO-178C objectives	They write the requirement. Keep them. Proof does not replace the standard and is not a qualified tool.
SPARK / Frama-C	FM.3: properties of source	They still win on Ada and C at the code. Proof does not prove the Go. Keep them.
VectorCAST / LDRA	A qualified C toolchain and structural coverage of object code	They still win when a DER stamps the kit. The four-jobs H1 lives on DO-178C-style.
Proof	Kind2 on HLR/LLR, Z3 on a data lemma, then the same audit on every push	No FM.3. No DO-330. FLIP MC/DC is specification-level. Tests are not executed.

The generate path is a view of the same graph, not a second source of shalls:

proof doc generate verification-report --format html --output docs/verification.html
proof audit --fail-level warn

Unknown template names fail before render. The report shows current verification states from loaded project data. Treat it as a print of the graph. If the graph is thin, the report is thin. We have not run Kind2 against a frozen DO-333 corpus, and we have not scored it against SPARK on the same pack. The loss is named, not scored.

03 · The honest loss

A green Proof audit is not DO-333 credit.

Credit under the supplement requires a qualified tool. Proof is not qualified under DO-330. A named reviewer is not a DER.

FM.4 says formal analysis can replace some testing. FLIP measures specification-level MC/DC. Code-level MC/DC on C still wants the qualified toolchain. That H1 lives on MC/DC for Go, not here. Proof generates inputs. It does not run them. Keep go test.

FM.5 is tool qualification. That is DO-330. Volume on that string is real. The page is not. Qualification is planned. Until then, use Proof output as input to review, not as a substitute for a qualified kit.

ARP 4754A sits above this: FHA, PSSA, allocation to software. Proof can take those shalls in. It does not perform the assessment. IEC 61508 is the parent industrial standard. The automotive software document lives on ISO 26262. Jama still authors. The four jobs still live on that URL.

Request demo How the install is bought

04 · Nearby questions

What people type next.

I need DO-178C style verification but I'm not in aerospace. What can I use? The four jobs, not the Type Certificate. DO-178C-style.

How do I prove a specific function meets its specification using something like Z3 or Kind2? A lemma on the Go function. Different H1. Z3 / Kind2.

What is DO-330? Tool qualification. Proof is not qualified. Keep VectorCAST or LDRA if a DER has to stamp the kit.

What is ARP 4754A? Aircraft system development above software. Proof does not run FHA or PSSA. Keep the system safety assessment.

What is a requirements traceability matrix, and how do I keep it true? DO-178C wants the links re-derived, not pasted. RTM.