Proof — Continuous Correctness Audit
We find where your code breaks its promises — and hand you the failing test.
Your application makes promises. We turn them into verifiable requirements that run in CI — and hold every commit to them. If we can’t hand you a failing test, we don’t file a finding — no finding, no noise.
one question before the receipts
How sure are you?
the receipts answer — keep scrolling ↓
Don’t take our word. Rerun it.
We don’t show customer logos. We show ledgers. Every number without a † on this page traces to a public audit you can open, re-run, and argue with — today.
case study — buger/jsonparser
A 5,600★ Go JSON library, more than ten years in production. 123 requirements signed by name, 7 findings fixed upstream in public PRs — and 1 published miss with a public postmortem.
| project | requirements | findings | status | ledger |
|---|---|---|---|---|
| buger/jsonparserGo JSON parser · 5,600★ · 10+ yrs in production | 123 signed | 7 fixed · 1 miss published | gate live | open ledger → |
| message queuedelivery & ordering promises | — | — | in scoping† | dossier on request† |
| payments SDKidempotency & retries | — | — | in scoping† | — |
| feature-flag servicetargeting & kill switches | — | — | in scoping† | — |
| workflow engineexactly-once execution | — | — | in scoping† | — |
† illustrative — engagements in scoping; the rows show the shape of the table, not claims. We list an engagement only after the owner signs the requirements. The table is built for ten rows; it fills as they sign.
every number above traces to the public jsonparser ledger — nothing aggregated, nothing projected.
What does your code actually promise?
More than anyone wrote down. An engineer says: “Set() replaces the value.” Proof turns that sentence into an object your CI can enforce. Three objects, in fact.
1 · the promise
“Set() replaces one value. Every other value survives.”
Lives in a doc comment and three engineers’ heads. Tested nowhere.
2 · the requirement
“When Set() writes one value, every other value survives.”
- acceptance criteria attached
- contradiction-checked, by machine
- signed by your engineer — by name
3 · the gate
Runs in your CI. Every commit, forever.
- 179 checks per run
- a broken promise fails the build
- exit 1 blocks the merge
a“Your code knows what it does — not why. We dig the promises out.”
b“Each promise becomes a requirement your engineers sign — with its acceptance criteria.”
fine print — formalization runs on Kind2 and Z3 with FRETish patterns; vacuous requirements are rejected before they count. You never need those names: the gate reads pass or fail.
What happens when a promise breaks?
This is the part we hand you. One real finding from the public jsonparser audit, start to finish — it plays itself in about twenty seconds.
Who checks the checker?
Machines check everything, every time. People sign what machines can’t: the promises, the bar, and our mistakes.
machines check
instruments: MC/DC · Kind2/Z3 · vacuity checks — the tools, not the point.
people sign
what people do not do: re-read your diffs one by one. That job belongs to the machines.
Findings never wait on a person. Their authority is a reproducer that fails on your main — you can re-run it without trusting anyone.
Software agents re-run every check and reproducer on every commit. We build on AI in the open — what no machine signs is the promises, the bar, and the mistakes.
Set() could silently drop sibling values. It passed our audit with every audited branch covered (100% MC/DC). A downstream user caught it. We published the postmortem under the founder’s name — Leonid Bugaev — blameless and public, and pinned the whole defect class so it cannot return.
“An auditor that only shows you its wins is asking for faith.”
What you walk away with
A signed source of truth
Every promise the component makes, recovered from its code, history, and tickets — written down and approved by your engineers. The spec exists outside the code and outside whoever wrote it.
A register of known issues
Every break between promise and code becomes a finding with a reproducer that fails on your current main — severity assessed against a signed, public bar, reasoning written down, open to challenge.
Coverage counted twice
Once against the code: every branch shown to matter. Once against the intent: every approved requirement bound to evidence — or the gate fails.
A gate in your CI
Plain YAML and executable tests that re-run on every release without us. Fixed defects can’t quietly come back, and every finding carries a prompt to start the fix.
fine print — condition-level MC/DC in eleven languages, Go and Rust to Solidity and Zig; formal verification on Kind2 and Z3; per-requirement hazard analysis. If you recognize the names, you know the lineage.
Known issues — jsonparser
every issue carries its reproducer, its severity rationale, and the requirements it affects — live, public, re-runnable.
Whose problem is this?
CTO / VP Engineering
“We ship ten times faster now. Review didn’t get ten times faster. I sign off on releases I can’t personally vouch for anymore.”
You stop vouching from memory and start pointing at evidence — signed requirements, a live gate, findings with proof attached.
Platform / Infra lead
“One bug in routing, auth, or billing hits every customer at once.”
Intent recovered and formalized, with coverage concentrated on the branches with the blast radius. The next change lands against a spec, not a guess.
OSS maintainer
“A small correctness bug in my library ripples into thousands of downstream builds — and nobody funds the boring verification work.”
High-signal external review, findings disclosed on your terms, and a regression corpus that protects every future release.
Stop hoping. Start knowing.
“Security firms audit whether your software can be broken into. We audit whether it works — and staying unbroken is part of working.”
Start with one component — the one you’d least like to be asked about under oath. The gate installs in your CI, and the corpus compounds from there.
proof · reqproof.com · sheet 01 of 01 · rev — continuous