continuous correctness audit
Your codebase has a map. Nobody drew the part that says what it is for. Proof draws it, and a gate keeps it true.
We find where your code breaks its promises, and hand you the failing test.
Proof’s own corpus: 1,990 requirements 21,796 machine-checked edges 190 checks per run 4 stale links reported today read the public audit
Two maps of the same repository.
Your code context tools draw the first map. It is built out of symbols, files and tests, and it answers where everything is. Proof draws the second map. Its nodes are the promises the software makes, and the code, the tests and the documents hang off the promise they serve.
A new engineer can read your repository in an afternoon. So can a coding agent. Intent is the one thing neither of them can read, because nobody wrote it down. They recover purpose by reading the implementation, and the implementation is the thing they were asked to change. That is how a confident, wrong change gets through review.
A graph of what the code is for, not only what it is.
Map 01 · read out of the code
- Every node is a symbol. Every edge is inferred from the source as it stands today.
- It answers where a function lives and which file it sits in.
- It carries no record of what any of it was supposed to do.
Map 02 · written down and signed
- Every node is a requirement, written down, and signed by the engineers who own the component.
- Every edge says implemented by, verified by, or documented by, and every edge is checked on every commit.
- The audit trail is the same object your agents read before they touch the code.
What that buys an agent
- Before the change: the component states its promises, so purpose does not have to be guessed from the implementation.
- After the change: the gate re-runs and says whether each promise still holds.
- A change that reads well and breaks a promise turns the gate red.
An inferred map ages the moment the code moves, and whoever trusts it does not get told. Proof holds its map against the code on every commit, and reports the links that no longer land.
findings and hazards are attached to requirements and checked separately. the dependency modelled here is intent dependency: what a promise needs, what verifies it, what documents it.
What is in the graph.
The numbers here are Proof’s own corpus, the codebase we run Proof against every working day. 21,796 machine-checked edges join 1,990 requirements to the code that implements them, the tests that verify them and the documents that describe them.
The edges come from annotations your engineers and your agents write in the source: 13,406 // Verifies: lines and 3,285 // Implements: lines. 94.5% land on a symbol, one function inside a file, so the graph knows which function carries the promise and which tests answer for it.
fig. 02 · One node, and everything hanging off it. Schematic of a single requirement in the graph. The annotation lines at bottom left are what create the edges, and they live in your source under your licence. The bar at bottom right is the real split: most implementation links resolve to one function, so the graph can answer questions about a symbol.
the graph is checked in place. export is neighbourhood scoped: you name a node and get what surrounds it.
Ask it something.
These are real runs against Proof’s own corpus. Your engineers ask it what moves before they start, and so do your agents, from the same command line.
If I change this promise, what moves with it?
the commandproof trace impact STK-REQ-019
the answer- affected
- 130
- requirements
- 31
- implementation files
- 10
- test files
- 33
- documentation files
- 56
- cycles
- none
The walk follows requirements, tests and annotations, so it reaches the documents a code reader would have missed.
What is this function for?
the commandproof req show --file <path> --symbol <Symbol>
the answerThe requirements attached to the file, listed separately from the requirements attached to the symbol inside it. In the run we checked, the symbol resolved to a single requirement, which is the promise that one function answers for.
A reader who opens the file gets the file. A reader who asks about the function gets the function.
Which tests must run for this change?
the commandproof test affected
the answerThe specific test that answers for what you touched, and the exact tests to run printed as a command your engineer or your agent can paste.
The selection comes from the requirement links, so a test that guards the promise is selected even when the file you edited is nowhere near it.
fig. 03 · The blast radius of one promise. Every mark is a real count from proof trace impact STK-REQ-019 on Proof’s own corpus. The walk runs through requirements, tests and annotations, and it reports whether it found a cycle.
the same results are available as structured output for machines. a JSONL audit stream carries the run, and exit codes carry the verdict.
The graph cannot go stale without the gate saying so.
The gate re-runs on every commit. All 190 audit checks run again, in the same order, with the same rules. When a commit moves the code out from under a link, that link is reported as suspect and a person looks at it.
On our own corpus today, proof trace suspect reports 4 stale links. We put the live number on the page because a graph held against a moving codebase carries some drift at any moment, and the honest thing is to publish the count.
fig. 04 · The same drift, two outcomes. Schematic. In both rows the code moves the same way. The difference is whether anything re-checks the link afterwards, and whether the number that comes back is published.
structured exit codes and a JSONL audit stream carry the same verdict to whatever reads it, including your CI and your agents.
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
- 190 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. A person decides what reaches 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.
The rule for agents
- Anything a coding agent creates through Proof is stamped
ai_generated: true, status draft, review pending. - An agent cannot approve its own requirement. The product enforces it.
- A person approves the draft, and only then does the gate start enforcing it.
Machines produce the volume. People produce the judgment. Every finding arrives with a reproducer that fails on your current main, so you can re-run the whole argument on your own hardware.
fig. 05 · Who is allowed to approve. Schematic of a rule the product enforces. A coding agent can draft a requirement and can write the annotations that bind it, and the draft stays a draft until a person with the authority to own it approves.
instruments: condition-level MC/DC in eleven languages, formal verification on Kind2 and Z3, FRETish patterns where a requirement needs a temporal shape. these are the tools. the product is the graph 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.
Set() could drop sibling values without reporting an error. It escaped an audit of that code, and a downstream user found it and told us.
We published a blameless postmortem, signed by Leonid Bugaev, and pinned the 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 register · findings bound to requirements
the graph · one finding, traced to its 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 graph and the tests whatever happens to us afterwards. They sit in your repository under your licence, in plain text your engineers can read and edit.
The graph of intent over your component
Numbered, testable requirements approved by the engineers who own the component, each bound to the code that implements it, the tests that verify it and the documents that describe it.
A register of known issues
Each entry carries a severity, a description your product manager can read, and the requirements it affects.
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. Red blocks the merge.
An audit page your board and your customers can read
Public or private, your call. It answers the due-diligence questionnaire with a link.
Your engineers use it before the change
They ask what a component promises, what a change moves, and which tests answer for it. The graph gives the same answer to the engineer who wrote the code and the one who joined last week.
The gate answers after the change
190 checks run on the commit. A promise that no longer holds turns red with a failing test attached, so the review argues about evidence.
A new engineer reads intent, then code
The requirements are the reading order. The code, the tests and the documents hang off the promise they serve, so purpose arrives before implementation.
How we install it.
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 graph is yours from the first day.
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, binding each one to the code and the tests, and putting every requirement in front of its owner for approval.
Then you live in the graph and the dashboard
Requirements, the register of known issues, the evidence behind each finding and the coverage numbers, in one place. Your product managers, your board and your customers under NDA can read it without opening the repository.
A person validates it before it reaches you
The machines run all 190 checks on every commit and produce candidates. A person decides which of them your team ever sees.
Your agents drive Proof from the command line.
The graph is built for the tools your team already runs. Everything an engineer can ask, an agent can ask the same way, and the gate answers to both.
- Hooks install into Claude Code and Codex, so a failed audit blocks the agent from finishing its turn.
- 41 embedded doctrine playbooks can be emitted agent ready, so the working rules travel with the repository.
- A structured exit-code contract carries the verdict, and a JSONL audit stream carries the run, both built for machines to read.
- Anything an agent drafts arrives stamped
ai_generated: trueand waits for a person to approve it.
- 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.
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. You end up with the map, and a gate that keeps it true.
[email protected] · reqproof.com
the public register: portal.reqproof.com/projects/jsonparser
proof · reqproof.com · sheet 01 of 01 · rev continuous