continuous correctness audit
Your software makes promises nobody wrote down. Proof writes them down, and holds every commit to them.
We find where your code breaks its promises, and hand you the failing test.
public audit: buger/jsonparser 123 requirements approved 179 checks per run 7 findings fixed upstream 1 published miss read it yourself
The last three weeks disappeared into bug fixing.
Engineering leaders describe the same week to us, in almost the same words.
"A release that doesn't bounce. The last three weeks stop disappearing into bug fixing."
VP Engineering
"Stop the whack-a-mole: we fix one thing and break another and nobody can promise it won't recur."
CTO
"Know what's actually broken before our biggest customer finds it in prod."
Head of Platform
"My senior engineers on the roadmap. Right now two weeks of senior time went into reproducing one customer's fault-tolerance bug."
CTO
"When the board or a big prospect asks how do you know it works, something better than CI is green."
VP Engineering
near verbatim from scoping calls. roles only, by request.
The promises are real and everyone knows them. A retry must never duplicate a write. A parser must reject a malformed number. A billing job must be safe to run twice. They live in a design doc from 2023, in the head of an engineer who left, in a comment above a loop. Nobody wrote the promises down in a form a machine can check, so nothing checks them. Your CI checks that the tests you happen to have still pass.
fig. 01 · The blast radius of one unwritten promise. Schematic. The promise exists in prose, so no check can fail on it. The failure surfaces at the widest ring, where your customers are.
You end up knowing what your software promises.
Proof turns the promises into three things your team can hold and read: requirements your engineers sign, a register of known issues, and a gate in your CI. They outlast the engineer who wrote the code and the quarter you bought them in.
Requirements your engineers sign
We recover what the component was supposed to do and write it as numbered requirements. The engineers who own the component read each one and approve it.
After that the requirements are theirs. They are the reference every later check is measured against.
A register of known issues
Every open failure mode in one list, with a severity, a plain description, and the requirements it breaks. Nothing is buried in a PDF.
Your team reads the same register we do. So does anyone you choose to show it to.
A gate in your CI
The requirements become tests that run on every commit, alongside the tests you already have.
When a commit breaks a promise the gate turns red and the merge waits. That is the whole enforcement story.
fig. 02 · Where the three artifacts sit. Signed requirements and the register are what the gate enforces. Commits pass through it, and one that breaks a promise stops there.
the requirements are written as numbered, testable statements in your repository. FRETish patterns are used where a requirement needs a temporal shape.
When a promise breaks, you get told, and you get the test.
This one is on the public register. A boolean parser accepted the input trueish as true, because it matched a prefix where the promise asks for an exact token. Here is the whole life of that finding.
fig. 03 · One finding, start to finish. Drawn from KI-11 on the public jsonparser register. Every step is a link you can open.
A finding is a test that fails on your main, with the exact input that breaks it. Your engineers run it, watch it fail, apply the fix and watch it pass. Nobody has to take our word for the severity, because the test is the argument.
reproducers are generated against the requirement, then minimised. condition-level MC/DC drives boundary and negative-case selection.
Who checks the checker.
Machines run every check, on every commit, at a volume no team could work through by hand. A person validates every finding before it reaches you. People sign the promises, the methodology bar, and the published misses.
You never open a finding that nobody checked.
Scale · the machines
- 179 checks run against the component on every commit, in the same order, with the same rules.
- Nothing is sampled. The whole component is checked every run, which is the part a team cannot do by hand.
- The run produces candidates. It does not produce your dashboard.
Judgment · the person
- A person validates every finding before it reaches your dashboard. That is the quality gate, and it is why your inbox stays worth reading.
- Noise gets dropped at that gate, so your engineers spend their attention on real breaks.
- Signatures go on the promises, the methodology bar and the published misses.
Evidence · what you re-run
- Every finding arrives with a reproducer that fails on your current main.
- Its authority comes from that failing test, so it does not depend on trusting us.
- You can re-run all of it yourself, on your own hardware, without us in the room.
Machines produce the volume. People produce the judgment. The reproducer means you can re-run either one and check the answer yourself.
fig. 04 · Coverage, counted twice. Schematic. A green suite reports the first bar. The second bar is the one your promises live in, and it is the one Proof counts.
instruments: condition-level MC/DC in eleven languages, from Go and Rust to Solidity and Zig. formal verification on Kind2 and Z3. FRETish requirement patterns. these are the tools. the product is the promises and the gate.
Read the register before you talk to us.
We run this audit in the open on buger/jsonparser, a Go JSON library with 5,600 stars and more than ten years in production. The register is public. Every requirement, every open issue and every fix is on a page you can open right now.
One published miss, MISS-001.
Set() could drop sibling values without reporting an error. It escaped one of our audits of that code. A downstream user found it, and told us.
We published a blameless postmortem, signed by Leonid Bugaev, and pinned the whole defect class so the same shape of bug turns the gate red on the day it returns. An auditor that only shows you its wins is asking for faith.
the dashboard · 01 the signed requirements
the dashboard · 02 the register of known issues
the dashboard · 03 requirements bound to evidence
MISS-001 escaped an audit with 100% MC/DC on the affected code. that is why coverage is counted against intent as well as against code.
What you walk away with.
Four artifacts, and you keep the requirements and the tests whatever happens to us afterwards. They sit in your repository under your licence.
A written set of requirements for the component
Numbered, testable, and approved by the engineers who own it. The reference for every check that follows.
A register of known issues
Each entry carries a severity, a description your product manager can read, and the requirements it breaks.
A test suite bound to the requirements, running as a gate
Every reproducer we wrote stays in your suite and runs on every commit, in your CI, on your runners.
An audit page your board and your customers can read
Public or private, your call. It answers the due-diligence questionnaire with a link.
fig. 05 · A defect class stops recurring. Schematic. Once the reproducer is in your suite, the release that would have reintroduced the bug turns the gate red instead.
Four weeks with your engineers, then the dashboard.
Onboarding is personal and it takes our team. That is the reason the requirements come out right: they are written with the people who know the component, so the requirements are yours, not ours.
Four weeks with the engineers who own it
We work alongside them: reading the code, recovering what it was supposed to do, writing the requirements and putting each one in front of the owner for approval. This part is hands on, and it is where the accuracy comes from.
Then you live in the dashboard
Requirements, the register of known issues, the evidence behind each finding and the coverage numbers, all in one place. It is readable by people who will never open the repository: your product managers, your board, your customers under NDA.
A person validates it before it reaches you
Nothing lands in your dashboard until a person has checked it. The machines run all 179 checks on every commit and produce candidates. A person decides which of them your team ever sees.
- scope
- One component, chosen with you.
- time to install
- Roughly four weeks.
- commercials
- Fixed fee, agreed before work starts.
- afterwards
- It re-runs on the cadence you choose. Optional fix sprints arrive as pull requests your engineers review.
Whose problem is this.
Three people ask us for this, and they all describe the same object: the component you can least afford to be wrong about.
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 answer to "how do you know it works" that a board or a large prospect can read, and a gate that keeps the answer current.
Head of Platform
"One bug in routing, auth, or billing hits every customer at once."
The component with the widest blast radius gets a signed set of promises, a register your team reads daily, and a gate on every commit.
Open source maintainer
"A small correctness bug in my library ripples into thousands of downstream builds, and nobody funds the boring verification work."
A public register your downstream users can read, and reproducers that stay in the suite long after the audit ends.
Start with one component.
Pick the one you can least afford to be wrong about. We scope it with you, agree a fixed fee, agreed before work starts, and spend roughly four weeks with the engineers who own it.
[email protected] · reqproof.com
the public register: portal.reqproof.com/projects/jsonparser
proof · reqproof.com · sheet 01 of 01 · rev continuous