The report
- When dated, signed, filed
- CI not this merge
Topic · Continuous check
What does a continuous correctness check in CI look like?
The same proof audit you run locally, on every push, with --fail-level warn. A quarterly PDF is a date. Exit 2 is a warning that still fails the job.
proof audit --fail-level warnSonarQube still scores the ruleset. Crowdtesting still exercises the product. Neither re-reads the shall on the merge.
01 · A report is a date
Continuous means the check is the merge, not a slide from last quarter.
The instrument is not a new analyzer. It is proof audit with a fail-level, so a warning is not silent.
The buyer question “is there an independent check” lives on the correctness-audit page. How you buy the install lives on the audit page. This page is the CI shape: what the job actually runs, and which exit code fails the merge.
From the workflow guide: --fail-level warn exits non-zero on warnings or errors. error waits for errors. Exit 0 is all checks pass. Exit 1 is at least one error at the selected level. Exit 2 is warnings only when fail-level is warn. That is the gate. A PDF attached to a ticket is not.
proof audit --fail-level warn
proof audit --check acceptance_criteria_witnessedThe first command is the job. The second is the stakeholder floor inside it: a testable shall without an acceptance witness is a finding, not a style note. Unit tests on children do not count as that witness.
02 · The exhibit
Same shall. Two clocks.
Last quarter the PDF said the component was reviewed. This push the shall has no witness. Click the tabs.
The shall
The files moved. The PDF did not re-read them.
Unasked this pushThe PDF
Still on the share. Still last quarter.
File existsProof
- Job proof audit --fail-level warn
- Exit 2 when the shall has no witness
Same shall. Two clocks. Click the tabs.
| What ran | Green? | What it looked at |
|---|---|---|
| Quarterly audit PDF | Then | A date. The files on this branch are newer. |
| SonarQube quality gate | Often | The ruleset. Not the shall. Keep it. Proof vs SonarQube. |
| Crowdtest / pentest pass | On the sample | The product as a customer, or whether you can be hacked. Correctness vs security. |
proof audit --fail-level warn |
No, here | Approved shalls on this commit. Exit 2 is warnings that still fail the job. |
If the job is “score new code against a ruleset,” keep SonarQube. If the job is “did this merge still keep the shall,” the check has to run on the merge. Proof does not invent the shall. It fails the job when the signed one has no witness.
03 · The honest loss
This is not a GitHub Marketplace action, and it is not SonarQube.
A green audit means the checks we selected passed on the approved shalls. It does not mean those shalls are the promises a customer heard.
We have not run Proof and SonarQube, or Proof and a quarterly audit firm, on the same frozen corpus. Jama still wins at programme authoring. The quality gate still belongs to SonarQube. Crowdtesting still belongs to the firms that exercise the product. Proof is not a one-click Action. Someone still has to install it on one component and keep the shalls signed.
The independent-check question stays on software correctness audit. How the engagement is bought stays on the audit page. Requirements coverage as a denominator stays on test coverage vs requirements coverage.
04 · Nearby questions
What people type next.
Can I get an ongoing audit that re-runs on every release instead of a one-time report? Same gate, commercial shape. The audit page.
How do I get an independent check that my software actually does what we promised customers? The service question, not the CI job. Software correctness audit.
How do I scale AI coding agents without quality collapsing? Quality-gate vs requirement-gate. Proof vs SonarQube.
What's the difference between test coverage and requirements coverage? Two denominators, not a CI clock. Coverage vs requirements.