Continuous Correctness Audit
Install Proof on one consequential component.
A Continuous Correctness Audit builds the approved requirements, graph, evidence corpus, known-issue register, change history, and CI gate for a component your business depends on.
Explore a live graph → seeded showcase branch; read the labels first
01 · The offer
We audit whether your software does what you promised.
A Continuous Correctness Audit is a standing engagement against a written bar. We formalize the requirements for one component you choose with us, your engineers approve them, and we prove and test the code against every approved clause. The findings, the proofs and the gate stay in your repository, where your CI reruns them on every release.
The claim is bounded on purpose: within a declared scope, for declared behaviors, with evidence commensurate with the consequence of failure. A person validates every finding before you see it, so we take a small number of engagements at a time.
The audit is how Proof gets installed. Proof is what stays. The graph, the records and the gate keep running whether or not the engagement continues. What Proof is, in full, is on the product page.
02 · Three parts
How it is bought.
A fixed-fee install, a monthly standing audit, and fix work that is scoped separately. We agree the shape in writing before we start.
The install
One component, chosen with you; a fixed fee quoted before work starts. Roughly four weeks from the first call to a gate in your CI, re-verification of your fixes included. Everything it produces is yours, whether or not you continue.
The standing audit
After the install, the audit that does not expire: reruns on the cadence you choose, per release, weekly, even daily. Each quarter, one more component comes under the bar, install-grade, sized into the retainer at scoping. Section 06 is what a month buys.
Fix sprints
Every register entry ships an agent-ready prompt with the reproducer as the finish line; your engineers or your coding agents can burn the queue down. When you want it done for you: fix sprints, scoped and priced separately, delivered as pull requests your engineers review and merge. The gate grades every fix.
One rule holds across all three. Fix work is never bundled into the audit fee, so the audit's economics never depend on how much fixing it finds, and the party grading a fix has no stake in having written it. The audit reads your code; it does not write it. Only fix work writes, and only through pull requests you accept.
03 · The install
Four weeks to stand it up.
Roughly four weeks from the first call to the gate running in your CI. Week one takes about two hours of the owners' time, because the drafting is ours.
- Week 0
Scope one component, countersign the NDA
We agree the shape and the fee before work starts. We countersign your NDA before reading a line.
- Week 1
Requirements the owners approve
We index the code first, then its history and the places intent lives: the tracker, the support queue, the docs nobody updated. Your engineers approve every requirement before any code is judged.
- Weeks 2–3
Worst cases, obligations, evidence, first findings
Approved requirements become formal properties. We check the specification itself for realizability, consistency and vacuity, so a bad clause cannot condemn good code. Where code and approved requirements disagree, we write it up.
- From week 4
The gate goes live
The evidence corpus lands in your repository and the gate wires into your CI: a broken requirement blocks the merge. We walk your team through every finding and every proof. That is the end of the install, not of the audit.
A person validates every finding before you see it. Agents do more of the crunching every month; a person stays on the line between machine and judgment.
From your side
What we need from you.
Three things. Proof reads your code; it does not write it.
Two or three engineers who own the component
A few hours a week while we install. They know what the code is meant to do; we write it down with them.
A repository we can read
Public, or private under NDA with read-only access. Private stays private.
One person who can approve
You set an assurance level on every requirement. Where it demands a person, someone who owns the code approves; below that line an agent may approve its own draft, and the record says so.
04 · The graph
What the install leaves running.
The install does not end in a report. It ends in a graph of what the component must do, bound to the code that implements it, the evidence that supports it, the issues that remain open, and the changes that follow.
The graph
Requirements, hazards, obligations, code, documentation and evidence hang off the component that owns them. Select a component, a requirement, a known issue or a change, and the graph answers what it rests on and what rests on it.
Blast radius
Before anyone touches the code, the graph answers what else is being touched: which files, which tests, which parent requirement, which obligations have to be re-earned.
Change records
Every change records why the behavior changed, which component owns it, which requirements it introduced or affected, and which evidence made the result acceptable. A commit says what text moved; a change record says what the system now promises.
Defect records
Open problems stay known issues. When the issue is fixed, Proof creates a verified defect record that preserves the fix and its evidence, with the reproducer kept as a permanent regression test.
Self-invalidation
When code, documentation or a dependency moves, the affected evidence goes stale. Proof does not declare the requirement false. It withdraws yesterday's confidence until the affected obligations are reviewed or rerun.
Agent access
Your coding agents read the same components, requirements, dependencies, obligations and evidence your engineers read — served over MCP to any MCP client. The agent starts from approved intent instead of rediscovering the system from raw code. What the agent receives →
Handover
The graph is not a hosted secret. Requirements, source annotations, tests, findings, coverage evidence and formal logs are plain files in your repository, under your licence, and they leave with you.
Fig. 01 · What the install builds: one component, its requirements, its open issues and its change history, with the evidence bound to each.
- If this changes
-
- 5 files
- 13 tests
- 1 parent requirement
- related obligations
The blast radius is answered before the edit, not discovered after the release.
05 · What stays behind
The audit is a file tree in your repository, not a PDF in your inbox.
Everything lands in your repository, under your licence, in formats your CI already runs. Plain files: requirements, source annotations, tests, findings, coverage evidence, formal logs.
your-repo/ ├── specs/ │ └── <component>.req.yaml ← approved by your engineers ├── src/… ← // SW-REQ-XXX ├── tests/… ← // Verifies: SW-REQ-XXX ├── changes/ │ ├── CHANGE-XXXX.yaml ← what the behavior now promises │ └── DEFECT-XXXX.yaml ← the fix and its evidence ├── evidence/ │ ├── findings/F-XXX_test.go ← runnable, and it pins the break │ ├── coverage/<component>/ ← condition-level coverage │ └── formal/<component>.log └── .github/workflows/proof.yml ← the gate
On the public project the paths are specs/{stakeholder,system}/requirements/, proof/known-issues/, proof/problem-reports/ and proof/evidence/ — open them.
Reproducers, regression pins, condition-level coverage (MC/DC), formal checks on the requirements, plain YAML and executable tests. The dashboard is a window over that corpus; the record itself stays in your git. Prefer no hosted portal? The same views ship as generated static reports.
Captured on proof-demo (on our probelabs/jsonparser fork), our showcase branch, on 3 August 2026. The open findings visible in it are seeded demonstration entries, deliberately left broken; the fixed records are the real ones. We list that as a limitation.
06 · The standing audit
Then it runs.
The four weeks are the expensive part: intent recovered, requirements approved, proofs built, the gate wired. What they buy is a corpus that makes every audit after them fast.
From week five the audit runs on the cadence you choose, per release, weekly, even daily: new and changed code held to the approved requirements, new behavior formalized into new clauses, every break a finding with a runnable reproducer, the register current for anyone who asks what is open.
The gate reruns mechanically on every merge regardless. The cadence you buy is how often an auditor reads what changed, extends the bar, and re-judges severities. Month twelve checks strictly more than month one.
After week four, the register does the work. Known issues become scheduled fixes the gate grades: your engineers, your coding agents working from the attached prompts, or our fix sprints when you want the queue off your plate. When a customer reports a bug, you check the register before you open a debugger.
One passing reproducer can prove the known instance is gone. Closing the whole defect class takes broader evidence: the sibling sweep, the hazard evidence, and the blast-radius verification behind it. When a defect does slip through, we widen the bar so its whole class cannot slip through again, and the miss is published.
It is priced as the expensive part precisely because everything after it is flat and compounding.
Read the method → How change and defect records work →
The record
What you keep when people change.
People move teams. Agents get swapped for better agents. The requirement your engineer approved stays where it is, and the gate keeps checking it.
Fig. 02 · A promise enters the record. It is still checked after the author leaves or the agent is swapped.
07 · Five commitments
Five commitments, in the contract.
Not aspirations. Each one is written into the engagement, and each one is checkable by you.
- Reproducer guarantee. No reproducer, no finding. Runnable or it does not ship. Every finding arrives with a reproducer we ran before delivery and the recorded result of that run, and a person validated it before it reached you. A reproducer pins the finding one of two ways: it fails until the fix lands, or it asserts the broken behavior while that behavior is live and flips when the fix lands. The record says which.
- Severity escalation. A finding we assess at our highest severity reaches your named contact within one business day of validation. It does not wait for the weekly report.
- Regression guarantee. Every fixed defect becomes a regression test in your CI. If the defect returns, your build fails before anyone has to remember it existed.
- Bounded claims, in writing. The scope, the behaviors and the depth of evidence are written into the contract. We sign what we checked and nothing beyond it.
- Zero lock-in. The gate runs without us. The corpus is plain YAML and executable tests in your git. If you cancel, everything that runs stays yours; what ends is our ongoing involvement.
08 · Exclusions
What we will not claim.
The list below is part of the offer. An audit that will not say what it cannot see is not worth buying.
- This is not a certified penetration test, and it does not satisfy a compliance requirement for one. Security promises inside the scoped component are audited like any other; black-box red-teaming, infrastructure testing, and social engineering stay with the security firms.
- Dependencies are held to their declared contracts. Auditing a dependency's internals is its own scope, quoted separately when you need it.
- This does not replace static analysis. Pattern scanners catch known bug shapes cheaply; keep them running. We audit against requirements the owners approved, which no scanner has read.
- We will not claim total correctness. No audit can. Our signature covers the declared scope and declared behaviors at the stated depth of evidence, and it stops there.
- Performance is out of scope. Throughput, latency and capacity belong with your performance engineers.
- Severity labels are ours: our assessment, weighted by reachability and impact; a starting point for your triage, not a CVSS determination.
The longer table of what this audit cannot see is on the methodology page. The register of what we have missed in public is on public proof.
09 · Fit
Before the form.
We would rather tell you no at scoping than take the fee and disappoint you at week four.
Worth your time if
- You can already name the component. Most readers who get this far can.
- A failure in it costs money or trust you can put a story to.
- Your release process is settled enough to host a gate.
- The engineers who own the component will give week one about two hours.
Not a fit if
- You need a certified penetration test or a compliance checkbox alone. We will say so at scoping and point you to a security firm.
- There is no owner who can approve requirements for the component.
- You want total-correctness guarantees; no audit can sell those, including this one.
The engine is language-agnostic; the published work is Go, and that is the only depth we can show you today. Python, Zig, Java, and C# are newer; we will tell you honestly where each stands. C and C++ arrive through the compiler's own coverage measurement, in the same gate. Another stack? Say so on the form and you get an honest timeline.
10 · Confidentiality
Private by default.
We countersign your NDA before reading a line of private code. No logos, and no names in public unless you publish them.
Open source, in the open
We read the public repository. Disclosure is on your terms, and the graph can be public, as it is for jsonparser.
Read-only, on your terms
We countersign your NDA first, then read with read-only access. Nothing about the work is public unless you publish it.
Start
Request confidential scoping.
Pick the component you would least like to be asked about. Every request gets a reply — a scoping call or an honest no.
Fees are quoted after scoping and fixed before work starts. We take on a small number of engagements at a time. Private code stays private. We countersign your NDA before we read a line of your code.
Prefer a call? Ask for 20 minutes →
Leonid Bugaev
founder · sets the bar, and publishes the misses