the map · what the requirements become
Your codebase has a map. Nobody drew the part that says what it is for.
Your code context tools draw the first map: symbols, files, tests, and where everything is. Proof draws the second map: the promises the software makes, with the code, the tests and the documents hanging off the promise they serve.It is the same map your agents read, from the command line.
Proof’s own corpus1,990 requirements21,796 machine-checked edges190 checks per run4 stale links reported today
A graph of what the code is for, not only what it is.
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.
fig. 01 · The two maps. Schematic, drawn over one set of symbols. 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.
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.
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. 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 single function, so the graph knows which function carries the promise and which tests answer for it.
requirements, each one approved before anything is enforced against it.
edges, each one re-checked by the gate on every commit.
functions indexed across 2,853 source files.
audit checks per run, from annotation validity to coverage against intent.
the graph is checked in place. export is neighbourhood scoped: you name a node and get what surrounds it. a JSONL audit stream carries the run, and exit codes carry the verdict.
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?
$ proof trace impact STK-REQ-019affected 130 · 31 requirements · 10 implementation files · 33 test files · 56 documentation files · 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?
$ proof req show --file <path> --symbol <fn>The requirements attached to the file, listed separately from the requirements attached to the symbol inside it. A reader who opens the file gets the file. A reader who asks about the function gets the promise that one function answers for.
Which tests must run for this change?
$ proof test affectedThe specific test that answers for what you touched, printed as a command your engineer or your agent can paste. A test that guards the promise is selected even when the file you edited is nowhere near it.
fig. 02 · Every count is a real one from proof trace impact STK-REQ-019 on Proof’s own corpus. The same results come out as structured output for machines.
The graph cannot go stale without the gate saying so.
All 190 audit checks re-run on every commit, 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 publish the live number because a graph held against a moving codebase carries some drift at any moment, and the honest thing is to publish the count.
fig. 03 · 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.
An agent cannot approve its own requirement.
The product enforces it. Anything a coding agent creates through Proof is stamped ai_generated: true, status draft, review pending. A person approves the draft, and only then does the gate start enforcing it.
Your agents drive Proof from the command line. 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.
proof · reqproof.com · sheet 03 of 05 · rev continuous