continuous correctness audit
We find where your code breaks its promises, and hand you the failing test.Your engineers sign the promises. The gate re-checks them on every commit after that.
public on buger/jsonparser123 promises signed7 breaks fixed upstream1 miss published
A commit touches refund.go. The map shows the promises it carries.
fig. 00 · The living map, on an example payments service. Signed promises on the left, the code and tests that answer for them on the right, one known issue marked in red. It replays the last finding every fourteen seconds; hover any card to trace its edges.
Engineering leaders describe the same week to us, in almost the same words. The promises underneath it 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. Your CI checks that the tests you happen to have still pass. It has no opinion about the promises you never wrote.
“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
“When the board asks how do you know it works, something better than CI is green.”VP Engineering
near verbatim from scoping calls. roles only, by request.
Proof turns the promises into three things your team can hold and read. They outlast the engineer who wrote the code and the quarter you bought them in.
We recover what the component was supposed to do and write it as numbered, testable statements. The engineers who own it approve each one. After that the requirements are theirs.
Every open failure mode in one list, with a severity, a plain description, and the requirements it breaks. Your team reads the same register we do. So does anyone you choose to show it to.
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.
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. 01 · One finding, start to finish. Drawn from KI-11 on the public jsonparser register. Every step is a page 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.
You never open a finding that nobody checked.
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.
Scale · the machines
179 checks run against the component on every commit, in the same order, with the same rules. Nothing is sampled. The run produces candidates, not 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 in month nine.
Evidence · what you re-run
Every finding arrives with a reproducer that fails on your current main. You can re-run all of it yourself, on your own hardware, without us in the room.
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.
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. Every requirement, every open issue and every fix is on a page you can open right now. One of those pages is our own published miss, with the postmortem signed. An auditor that only shows you its wins is asking for faith.
requirements approved by the engineers who own the library.
findings fixed upstream, in public pull requests anyone can read.
checks per run, on every commit to the component.
published miss, with the postmortem signed and the defect class pinned.
All the receipts, including the miss →Open the live register ↗
Three people ask us for this, and they all describe the same object.
“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.”
What 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.
“One bug in routing, auth, or billing hits every customer at once.”
What you get: 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.
“A small correctness bug in my library ripples into thousands of downstream builds, and nobody funds the boring verification work.”
What you get: a public register your downstream users can read, and reproducers that stay in the suite long after the audit ends.
Pick the one you can least afford to be wrong about. We scope it with you, agree a fixed fee before work starts, and spend roughly four weeks with the engineers who own it.
Prefer email? [email protected] · the public register: portal.reqproof.com/projects/jsonparser
proof · reqproof.com · sheet 01 of 05 · rev continuous