We find where your code breaks its promises — and hand you the failing test.
We recover the requirements your code was supposed to meet, get them signed by your engineers, and hold every line to them — continuously, in your CI. Unlike a code review, every finding arrives as a reproducer that fails on your main. No finding, no noise.
Fixed fee · ~4 weeks to first gate · findings signed by name
$ proof audit --fail-level warn checking 123 approved requirements · 52 checks ✓ annotation_validity 123/123 ✓ coverage_against_intent MC/DC ✗ SW-REQ-041 boundary: negative index panic: runtime error — 8 call sites reproducer: TestGetNegativeIndex status: FAILS on main @ e1af7b2 1 finding · signed: Leonid Bugaev
Receipts, not references
Public audits you can re-run yourself
We don't show customer logos. We show ledgers. Every public audit below is a real engagement with every requirement, finding, and miss published — and a gate you can re-run against the repo today.
Public audits — re-runnable receipts
| Project | Requirements | Findings | Headline defect | Status |
|---|---|---|---|---|
|
buger/jsonparser
Go JSON library · 10+ yrs in production · 5.5k★
|
123 approved & signed | 7 confirmed, each with a failing test | 1 panic class reachable from 8 call sites |
1 open finding gate live |
|
— and one published miss
The defect our audit did not catch. Documented below, postmortem and all.
|
1published miss |
Set() silent data loss — passed with 100% MC/DC coverage
|
read the postmortem | |
every number above traces to the public jsonparser ledger — nothing aggregated, nothing projected
How it works
From unwritten promises to a gate in your CI
Three steps. The first two are the audit; the third is why it keeps paying after we leave.
We recover the promises
We read your component the way a formal-methods team would: extracting the requirements it implicitly makes — then your engineers review and sign each one. Nothing counts until a human with a name approves it.
id: SW-REQ-041 statement: "Get() with a negative index returns ErrOutOfRange, never panics." approved_by: human:buger status: approved
We hold code to them
Every signed requirement is checked against the implementation — SMT solvers (Z3), model checking (Kind2), and MC/DC coverage counted against intent, not lines. Findings must reproduce or they don't ship.
$ proof verify SW-REQ-041 ✗ FAIL boundary: idx < 0 reproducer written: TestGetNegativeIndex --- FAIL on main (e1af7b2)
The gate lives in your CI
The full requirement set, tests, and 52-check gate land in your repo. Findings arrive as failing tests with agent-ready fix prompts — your team (or your coding agents) fix; the gate grades.
your-repo/ ├── specs/ │ └── software/ 123 reqs ├── .github/workflows/ │ └── proof-gate.yml ✓ └── proof.yaml
How this differs
Not a review. Not a scanner. A gate.
Honest marks — the other columns are good tools that we use too. They just answer a different question.
| Capability | Code review | Test coverage | Static analysis | Proof audit |
|---|---|---|---|---|
| Finds unwritten promises | partial | ✗ | ✗ | ✓ |
| Findings arrive as failing tests | ✗ | ✗ | partial | ✓ |
| Coverage counted against intent | ✗ | ✗ | ✗ | ✓ |
| Re-runs without the vendor | ✗ | ✓ | ✓ | ✓ |
| Signed by a named reviewer | partial | ✗ | ✗ | ✓ |
The honesty section
We publish our own misses
Any audit vendor will show you what they caught. Here's what we didn't — on our own public ledger, because an audit you can't falsify is marketing.
The Set() data-loss defect our gate passed
During the jsonparser audit, a silent data-loss defect in Set()
slipped through our verification — with the requirement approved and
100% MC/DC coverage on the function. The tests exercised every branch.
None of them checked the property that mattered.
We wrote the postmortem, published it on the same ledger as our findings, and turned the failure class into a check the gate now runs on every audit.
# ledger: jsonparser / misses MISS-001 symptom: Set() drops sibling keys caught_by: downstream user, not us coverage: 100% MC/DC at time of miss root: property untested — branch coverage ≠ promise coverage action: new gate check shipped; re-runs on every audit status: postmortem published
Why now
Everyone ships AI code. Almost no one trusts it.
of developers distrust the accuracy of AI output — versus 33% who trust it. Distrust now outweighs trust.
— Stack Overflow Developer Survey 2025
of teams have adopted AI coding tools — while 30% report little or no trust in what those tools produce.
— DORA State of AI-assisted Software Development 2025
The gap between shipping code and trusting code is the fastest-growing liability in software. We close it with signed requirements and a gate — not vibes.
Engagement
Fixed fee. Agreed before work starts.
No hourly meters, no seat licenses, no surprise renewals. One number, quoted after scoping.
One component. ~4 weeks to the first gate. Then flat, month to month.
The questions worth asking
What do we keep if we stop?
proof audit is a command your team runs,
not a service you call. Stopping ends new findings, not the ones you have.
Do you fix what you find?
What can't the audit see?
How is the fee set?
Start with scoping
Pick the component that keeps you up at night.
Send an email address and, if you like, a sentence about the component. An engineer — not a salesperson — replies within one business day with scoping questions and a fixed quote.