Continuous Correctness Audit
The audit that doesn't expire.
An audit is usually a photograph: true the day it ships, stale by the next merge. Proof is a software correctness audit that stays installed, built from the verification discipline of industries where software is not allowed to fail. Your engineers sign off on what the component is supposed to do; we hold the code to it in your repo, on every release.
Continuous Correctness Audit
Code ships faster than anyone can vouch for it.
Proof is a continuous correctness audit practice. We audit whether your software does what you promised. Every finding arrives with a runnable reproducer that fails on your current main, validated by a named reviewer. Every fixed defect becomes a regression test in your CI.
Continuous Correctness Audit
“Verified” should be a claim you can re-run.
Proof is a continuous correctness audit practice for software that AI now helps write. We publish the bar we audit against. Every finding ships with a reproducer that fails on your current main, or it does not ship. Then the audit re-runs on every release.
Continuous Correctness Audit
AI writes your code. Who verifies the intent?
A model writes the function. A model writes the test that agrees with it. Neither knows what you meant. Proof audits your most critical component against requirements your engineers approve, and leaves the evidence corpus in your repo, re-run on every release.
Continuous Correctness Audit
The evidence layer AI-era code is missing.
Models write the code and the tests that agree with it; nothing in that loop knows what you promised your customers. Proof is the independent layer between the two: requirements your engineers sign, the code proven and tested against them, evidence that re-runs in your CI on every release.
Request confidential scoping Inspect the findings ledger
01 Your engineers sign the promises
You pick one critical component. Code knows what it does; it doesn't know why. We recover the why, from its history and the tickets where intent lives, into written requirements your engineers approve.
02 We hold the code to them
Proofs and tests against every approved requirement. Each break becomes a finding with a reproducer that fails on your current main, validated by a named reviewer.
03 It re-runs on every release
The audit stays in your repo as plain YAML and executable tests, and your CI re-runs it on every release. Fixed defects can't quietly come back.
Under the hood: formal verification (Kind2, Z3) · requirements management (FRETish) · code-level MC/DC in eleven languages, from Go and Rust to Solidity and Zig · hazard-style gap analysis. If you recognize these names, you know where this comes from. If you don't, § 4 tells the story.
The problem, lived from the inside.
Our founder spent years leading engineering at companies selling into the enterprise market. The pattern arrived on schedule, every time. Bigger customers brought edge cases the suite had never imagined, and contracts that assumed they were already handled. The test suite grew until it was its own scaling problem: more tests, slower builds, less confidence per test added. New features shipped regressions, regressions cost reputation, and in the enterprise market, reputation is the product.
That is not one company's story; it is the story of every product that grows. The evidence everyone trusts, green builds and finished tickets, measures effort. Nobody measures whether the code still does what you promised, and a test suite cannot catch a promise nobody wrote down. Catching that is audit work. AI didn't create the problem; it multiplied the code faster than anyone's ability to vouch for it.
Proof is what he built in response.
Security firms audit whether your software can be broken into.
We audit whether it works.
When the question is break-ins, you know who to call. That industry is decades old and very good. When the question is whether the software still does what you promised your customers, there has never been anyone to call.
And that second question is the one growing. In Stack Overflow's 2025 survey, 46% of developers said they distrust the accuracy of AI output, against 33% who trust it. DORA 2025 named the pattern: 90% adoption, 30% with little or no trust in what gets generated. The doubt is real, measured, and nobody's job.
A Continuous Correctness Audit makes it somebody's job.
Shipping model-written code? There is a page for exactly you →
The audit is a file tree in your repo, not a PDF in your inbox.
WHAT THE GATE SAYS
$ proof audit requirements realizability ✓ consistency ✓ vacuity ✓ traceability 100% precision 0 orphan code coverage MC/DC on every scoped decision findings 1 open F-003 reproducer RED on main audit gate 52 checks · 1 blocking · exit 1 the build fails until the fix lands · re-runs in your CI without us
WHERE IT LIVES
your-repo/ ├── specs/ │ └── refund-engine.req.yaml ← approved by your engineers ├── src/refund/engine.go ← // SW-REQ-142 ├── tests/refund/engine_test.go ← // Verifies: SW-REQ-142 └── evidence/ ├── findings/F-003_test.go ← fails on main until fixed ├── mcdc/refund-engine.json └── formal/refund-engine.log
This is the shape of the deliverable: the evidence corpus. The file names are examples; the structure is what lands. Requirements your engineers approve in week one, in plain YAML. Findings as executable tests that stay red until the fix lands. A gate wired into your CI. What you keep is a verification harness: reproducers, regression pins, condition-level coverage, formal checks, all built to re-run. If we stepped away tomorrow, nothing you rely on stops. The corpus ships with a dashboard over it: every requirement, every known issue, its evidence, readable by the people who will never open the repo. It is live for our public audit: browse the jsonparser register, findings, reproducers and all. And every known issue carries one button, copy the prompt, which hands a coding agent everything it needs to start the fix, reproducer included.
And coverage is counted twice: once against the code (condition-level MC/DC, every branch shown to matter) and once against the intent (every approved requirement and identified hazard bound to evidence, or the gate fails). Two separate 100%s, because they measure different things.
Vacuity, for the curious: a requirement so weak that a do-nothing system satisfies it. And 100% precision means every link that exists is verifiable and correct; precision, not recall.
Borrowed from the industries where software is not allowed to fail.
The strange words in that terminal have pedigrees. The requirements language descends from NASA's flight-software program, where a specification has machine-checked semantics or it does not fly. Realizability checking asks whether a spec can be built at all, before anyone builds it.
MC/DC is the coverage bar avionics sets for code whose failure is catastrophic: every condition in every decision shown to matter, on its own. And gap analysis asks the hazard-analysis question of ordinary software: what did nobody write down?
For forty years this discipline stayed inside regulated programs, because using it took certification-grade toolchains and a floor of specialists. That is the part that changed. The engine compiles the requirements, runs the solvers, and measures the coverage. The drafting that once required specialists is machine-assisted now, and anything the checkers cannot verify is rejected. An expert signs everything that ships.
Discipline this deep used to be a program milestone. Now it's a gate in your CI. Put one in yours →
Month twelve knows more than month one.
Every finding arrives as a failing reproducer; every fix converts it into a permanent regression test; every release adds requirements to the corpus. A point-in-time audit is a photograph. This one re-runs when the code changes, because that is when the risk arrives.
Risk becomes a plan
The known-issue register turns unknown risk into scheduled work.
Fixes grade themselves
Findings arrive as red tests. Humans or models fix them; the gate grades the result.
Field reports meet the register
Triage starts at "is this known", with severity and reproducer on file.
Misses retire whole bug families
Misses are root-caused and their siblings swept. The audit learns.
The full picture, month two to month twelve →
We publish our own misses.
Our first public audit was jsonparser, a Go JSON library our founder wrote and maintained for a decade: 123 formalized requirements, seven real bugs found, including one panic class at eight sites. Then a silent data-loss defect in Set() escaped that audit with 100% MC/DC on the affected code: valid JSON out, the rest of the data quietly gone. We published the postmortem of exactly how, in the repo, where you can re-run the finding and the fix.
An audit firm that only shows you its wins is asking for faith. Findings you can re-run are the alternative to faith.
Read the ledger, including the miss →
Fixed fee. One component. Roughly four weeks. Then continuous.
Scope
One component your business depends on, chosen with you. We scope it and quote a fixed fee, agreed before work starts.
Week one
Requirements approved by the engineers who own the component before any code is judged. Sign-off is the audit's foundation: the spec exists outside the code and outside whoever wrote it.
Afterwards
Optionally continuous: a standing retainer on the cadence you choose, per release, weekly, even daily, sized when scoped. The evidence corpus compounds, and the gate keeps running either way.
Every finding is signed by name, so we take a limited number of engagements each quarter. The full engagement, and the scoping form →
You can't forward a scroll position. Forward these.
/findings
For the staff engineer told to vet the vendor: dated entries, a validator on record for each, triage boundaries, one published miss.
/methodology
For the skeptic: the bar we audit against, the checks that enforce each clause, and a table of what this audit cannot see.
/trust
For AppSec and counsel: access models, data handling, disclosure policy, and key-person continuity, in one pass.
Wondering how any of this is possible? The instruments are their own page → And so is the practice behind the signatures →
Every finding carries a name.
Findings do not ship anonymously. A named reviewer validates and signs each one before it reaches you. The methodology they sign against is published, and the evidence re-runs in your repo, so the signature is checkable rather than ceremonial.
Request confidential scoping.
Not ready for scoping? The blog is the no-commitment way to keep track of us. Scoping is where the component gets named and its promises get written down. Your email is the only required field; the rest is optional context. We reply personally, with a scoping call or an honest no. Fees are quoted after scoping, fixed before work starts.