ProofContinuous Correctness Audit

Continuous Correctness Audit

Your agents write. Your humans sign. Proof remembers.

We find where your code breaks its promises, and hand you the failing test.

Proof is the written record of what your software promises, plus the gate that keeps checking it. The audit is how the record gets installed.

Request an audit See a live audit

Public audit: buger/jsonparser · register open at portal.reqproof.com

01 · The receipts

What we audited, and what it found

One public audit, on the Go JSON library buger/jsonparser: 5,600 stars, more than ten years in production. 7 findings fixed upstream in public pull requests, and one published miss. The register is open, and every finding on it is a test you can run.

123requirements, approved by the engineers who own the code
7findings fixed upstream, in public pull requests
1published miss, with a blameless postmortem
private engagement, an API infrastructure vendor

One release fixed three previously tracked issues and introduced two new High severity defects, inside otherwise valid fixes.

private engagement, the same vendor

A 14 commit delta passed 1,870 tests, and review still found an incomplete stack overflow fix, a live sibling of another corrected bug, and non-determinism in a new feature.

Both releases passed their own test suites before the gate ran.

Requirements Explorerthe signed promises
The Requirements Explorer view: a searchable table of requirements with component, level, approval status, assurance grade, formalization and coverage columns.
Every promise gets a row: the component that owns it, the level it sits at, whether your engineer approved it, and whether any evidence binds to it. Shown here running against our own codebase, which is why the counts are larger than the 123 on jsonparser.
Known issuesthe register
The known issues register: severity counters for critical, high, medium, low and info, and a table of open findings with identifiers, status, and the requirements each one affects.
The register on one run: ten open known issues, each with a severity, a status, and the requirement it breaks. Fixed and withdrawn entries stay on the record.
Trace mappromise bound to evidence
The trace map: one known issue node connected by affects edges to two requirements, each connected by verified by edges to specific source files and test files.
One known issue, wired up: the requirements it affects, and the code and tests bound to each of those requirements. Click through to the file.
MISS-001 · published misssigned

Set() could drop sibling values with no error. It escaped an audit of that code, and a downstream user found it. We published a blameless postmortem, signed by Leonid Bugaev, and pinned the whole defect class so the family cannot come back without failing the gate.

The affected code carried 100% MC/DC coverage at the time of the miss. Coverage of the code was full, and the promise still broke. The postmortem and the pinned class sit on the public register.

Open the live register and re-run any finding on it.

02 · The corpus

What Proof remembers

Three things, and they outlast the people and the agents who wrote the code.

  1. 01

    Requirements your engineers signed.

    We read the component and write down what it promises, in plain sentences. Then the engineers who own it approve each one by name. On jsonparser that came to 123.

  2. 02

    A register of known issues.

    Every open failure mode, with a severity, a status, and the promise it breaks. Fixed entries stay in the record, so a bug that came back is visible as a bug that came back.

  3. 03

    A gate.

    Each requirement compiles into checks. On jsonparser, 179 of them run on every change, and they run whether or not anyone is watching.

People change teams. Your agents get swapped for better agents. The sentence your engineer approved stays where it is, and the gate keeps checking it.

The record lives in your repository and in your dashboard. You can read it without opening the code.

SAID IN REVIEW, YEARS AGO “Set() replaces the value.” no test, no document, no owner a promise, nowhere on file we write it down, your engineer approves it THE CORPUS requirements, signed by name 123 of them on jsonparser the register of known issues severity, status, the promise each one breaks the gate 179 checks, re-run on every change in your repository and in your dashboard author leaves agent swapped release 41 release 42 the promise is still checked nobody has to remember it
Fig. 01 · a promise enters the recordhand drawn

03 · The finding

How a promise becomes a check that never stops running

One finding, start to finish. The figure follows a real one from the jsonparser audit.

  1. 01

    Said.

    An engineer wrote it in a review years ago: Set() replaces the value. Nobody wrote it down anywhere a machine could read.

  2. 02

    Signed.

    We write it as a requirement. The engineers who own the parser read it and approve it by name.

  3. 03

    Broken.

    A check fails. The finding is a test that fails on your main branch, and it names the promise it breaks. A person validates it before it reaches you.

  4. 04

    Fixed.

    The fix arrives as a pull request your engineers review. The same test passes on the merge commit.

  5. 05

    Pinned.

    The whole defect family gets pinned, so the class stays pinned on every release after. Removing the check fails the gate.

Severity is arguable, and we write the argument down so you can push back on it. The reproducer settles itself: it runs red on your main branch or it does not.

01 · SAID, IN REVIEW “Set() replaces the value.” an engineer, in a pull request, years ago 02 · SIGNED a requirement, approved by name the engineers who own the parser read it and approve it the promise now exists outside the code 03 · BROKEN a test that fails on your main branch it names the promise it breaks, and we argue the severity a person validates it before it reaches you 04 · FIXED UPSTREAM a pull request your engineers review the same test passes on the merge commit 05 · PINNED the whole class runs on every release after removing the check fails the gate one audit cycle, no meeting required
Fig. 02 · one finding, start to finishhand drawn
THE SAME BUG FAMILY, RELEASE BY RELEASE illustrative r.36 r.37 r.38 r.39 r.40 r.41 r.42 class pinned no recurrence since each cross is the same defect family coming back after the pin, bringing it back fails the gate
Fig. 03 · a defect family, release by releaseillustrative

Why the pin matters more than the fix

A fix closes one bug. The same family comes back two releases later, in a different function, written by a different hand. That is the whack-a-mole every platform team knows.

When we close a finding we pin the class it belongs to. The check for the family runs on every release from then on, and deleting it fails the gate. The bug you paid to fix stays fixed.

04 · The checker

Who checks the checker

Machines and software run every check, on every commit. That is data crunching at a volume no person could do by hand. Then people take over.

You never open a finding nobody checked.

Machines run, every commit

  • 179 checks on jsonparser, on every change.
  • Every reproducer re-run against your current main branch.
  • Coverage counted against the code, and against the written promises.
  • The requirement set scanned for contradictions.

People do the rest

  • A person validates every finding before it reaches your dashboard.
  • Your engineers sign the promises, one requirement at a time.
  • We sign the methodology bar, and it is public.
  • We sign the published misses, with a blameless postmortem each.

Every finding arrives with a reproducer that fails on your current main branch. You run it yourself, so its authority never rests on our word.

Under the hood: requirements are formalized in FRETish and checked for contradictions with Z3 and Kind2 before any code is judged. Coverage is measured at condition level (MC/DC) in eleven languages, from Go and Rust to Solidity and Zig. None of that vocabulary is needed to read the register.

YOUR AGENT YOUR ENGINEER writes the code signs the promise by name, in writing the code the promise THE GATE 179 checks, every change, no tired Fridays one fails a person validates it before it reaches you the quality gate your dashboard: the failing test it fails on your current main, so run it yourself
Fig. 04 · the gate grades bothhand drawn

05 · Why now

Your agents write more of the code every quarter

Review did not speed up to match, and trust did not keep up either. Two industry surveys say the same thing from different angles.

46%

of developers distrust the accuracy of AI output, against 33% who trust it.

Stack Overflow Developer Survey, 2025
~90%

adoption of these tools, with about 30% reporting little or no trust in them.

DORA, 2025

Reading every diff was already hard. It stops being possible once the diffs arrive faster than people can read them. The team still has to answer for the release.

So what a component promises has to be written down and machine-checked. A signed sentence and a failing test survive a review queue nobody can drain.

Both figures are self-reported industry surveys about developers and their tools. We cite them as context for the buying decision, and nothing on this page depends on them.

COUNTED AGAINST THE CODE COUNTED AGAINST THE PROMISES every line ran the suite is green eight promises unchecked no test binds to the red cells CI is green in both pictures the right one only exists once somebody writes the promises down
Fig. 05 · coverage counted twiceillustrative

06 · What you keep

What you walk away with

Four artifacts, and they are yours to keep. They stay useful whether or not we are still working together.

01

Requirements, in writing

Plain sentences describing what the component promises, each one approved by the engineer who owns it. New hires read them. So do your agents.

02

Findings, as failing tests

Each one names the promise it breaks, carries a severity we argued in writing, and comes with a reproducer that fails on your current main branch.

03

A register of known issues

Open failure modes with severity and status, and the fixed ones kept on the record. This is the artifact you hand to a board member or a due diligence questionnaire.

04

A gate, and a dashboard

The checks re-run on the cadence you choose. The results land in one place people can read, including the people who will never open the repository.

07 · How it lands

How we install it

Two phases. The first one is done by people, and that is on purpose.

Onboarding is personal

Roughly four weeks to install, working with the engineers who own the component. We interview them, read the code, and write the promises down. This part is not self-serve, and that is why the requirements are yours rather than ours.

Then you live in the dashboard

Requirements, the register of known issues, evidence, and coverage, all in one place. Your engineers open it to check a claim. Everyone else opens it to see where the component stands.

Nothing arrives unchecked

Nothing lands in your dashboard until a person has checked it. That is the quality gate, and it is why the register stays worth reading in month nine.

One component, chosen with you. Fixed fee, agreed before work starts. After the install it re-runs on the cadence you choose. Fix sprints are optional and arrive as pull requests your engineers review.

08 · Whose problem this is

Three people who feel this first

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 get a written bar and a gate that holds it. A release you did not read personally is still a release you can answer for, and the register answers the due diligence questionnaire without a fire drill.

Head of Platform
One bug in routing, auth, or billing hits every customer at once.

Then the blast radius sits in one component, and that is the component we install on first. Every promise it makes gets written down, and every Sev-1 you already survived becomes a pinned class.

Open source maintainer
A small correctness bug in my library ripples into thousands of downstream builds, and nobody funds the boring verification work.

jsonparser is the public one. The requirements, the register, the fixed findings and the published miss are all open, so you can judge the work before you talk to us.

The pattern behind all three: we fix one thing and break another, and nobody can promise it will not recur. A pinned class is that promise, in a form a machine enforces.

Start with one component

Pick the component where one mistake reaches every customer at once. We write down what it promises, your engineers approve it, and the gate takes it from there. Fixed fee, agreed before work starts.

Request an audit See a live audit
Leonid Bugaev
Founder, Proof

We sign the promises, the methodology bar, and every miss we publish. MISS-001 is on the public register with a postmortem attached.