For coding agents
Let agents own work you could not reliably delegate before.
Over MCP, the agent reads the graph before it edits a line: the requirement, its dependencies, history, hazards, the reproducer, the blast radius, and the verification obligations. That widens what a team can hand to an agent, from fix-ready bugs to changes it would not delegate to a general coding agent alone. The agent writes the change. Proof protects the agreement.
The live jsonparser graph answers anonymous MCP clients. No account, no token.
01 · Evidence
Start from a failure you can run.
The first thing the agent does is reproduce the issue — not decide whether a vague report sounds plausible.
A bug report describes a symptom. A reproducer is a test that pins the broken behavior: it either fails until the fix lands, or asserts the break while it is live and flips at the fix. The agent begins from the failing test, so the first thing it learns is what the software does.
The finding also names what closing it requires. The agent does not have to invent a completion test, and it cannot quietly choose an easier one. A feature, a refactor or a migration starts the same way, from the acceptance evidence agreed before the code is written.
The rest of this page follows one issue through: the intent around it, the reach of the change, the fix, the grade, and the evidence left behind.
- Kind
- known issue · fixed on master
- Violated requirement
- SYS-REQ-009
- Reproducer
- a test that pins the break, in your repository
- Observed
- unrelated structure is corrupted
- Required to close
- the reproducer passes, and the obligations on the requirement run again
The agent starts from evidence it can run.
02 · Read
Navigate by intent, not files.
A code graph tells you what calls what. Proof tells you what depends on what being true.
An agent that reads only the repository has to infer the promise from the implementation. It guesses, and the guess never appears in the diff.
In Proof the agent opens the component, reads what the component promises, and walks the intent above and below it. Three questions are answered before it writes a line: what does this component promise, why does this behavior exist, and what depends on it.
03 · Reach
Know the blast radius before editing.
The agent asks what a change can reach, and gets an answer before the first edit.
The answer is not a file list. It is the intent the change touches, the code and tests bound to that intent, the hazards that constrain it, and what already went wrong in the same place.
An edit that looks local but breaks a parent requirement is visible at the start of the work. That is the difference between a review that catches it and a release that ships it.
Returned to the agent
Relevant intent
SYS-REQ-009 · SYS-REQ-069 · SYS-REQ-110
Blast radius
1 component · 3 files · 8 tests · 3 hazard obligations
History
1 related defect record · 2 defect classes
04 · Fix
Make the fix. Proof grades it.
The agent does not close its work by writing a summary. It closes it by producing what the requirement asked for.
The grade is the obligations on the intent that moved: the tests, the properties, the documentation update, and the review the change needed. A passing reproducer establishes that the known instance is gone. Closing the wider class needs the broader obligations, the sibling sweep, the hazard evidence, and the blast radius verified again. A feature or a refactor is graded the same way, by the obligations on every requirement it moved.
Proof also grades what the change itself put in question. When the agent edits code, Proof identifies the relationships and the evidence that may no longer be current. It does not declare the requirement false. It withdraws yesterday's confidence until the affected obligations are reviewed or run again. Done means those obligations ran again.
05 · Retained
Leave the evidence behind.
The change record, reproducer, regression evidence, and approval remain attached to the requirement after the agent session ends.
When a known issue is fixed and the closure is verified, Proof writes a verified defect record that preserves the fix and its evidence. The record names the intent that moved, the requirements it touched, the evidence produced, and who approved it. It sits on the requirement, in your repository, and the next session opens it as context. A feature, a refactor or a migration leaves a change record of its own, naming why the behavior changed and the requirements it moved. The record shown here is one.
Evidence is never held as current on its own. It stays bound to the code version and the graph version it was produced against, and it carries its state: verified, or stale and waiting for a rerun.
- Type
- feature
- Title
- v1.5.0: Config, name aliases, streaming ReaderParser.
- Requirements
- SYS-REQ-115, SYS-REQ-116
- Impact review
- 19 requirements re-read across 4 files, every row fingerprinted
- Owner
- human:buger, target release v1.5.0
06 · The assurance model
You decide what still needs a person.
An agent can propose a requirement. Out of the box it can approve one too. Which levels stay open to an agent is one setting in your configuration.
Proof ships open. A new project starts with agent_autonomous_for: all: true, so an agent can approve at any assurance level from the first commit, and the record names the agent and the level it ran under. Human approval is opt-out, not opt-in: set all: false and list only the levels you delegate under assurance_levels. An empty list reserves every level for a named person.
The threshold is the assurance level, A to E — NPR 7150.2’s principle: the higher the consequence of failure, the more evidence and judgment the workflow demands. A is human safety. C is recoverable production infrastructure. E is demos. You declare the level per component and per spec; any single requirement can override it.
Until you narrow the policy it treats every level alike: an agent may approve at A as readily as at E. Narrow it and the levels split. Delegate C, D and E, keep A and B, and an approval at A waits for a person who owns the code while an approval at C records the agent and the level it ran under. proof approve refuses a level you have reserved, and the refusal names the setting that refused it. Either way the record says who or what approved, at which level, and under which policy.
The point is control, not a default. You decide which grades require your judgment, and that decision lives in one place. Where the grade carries real consequence, reserve it, and a person gives it by name. Widen what the agent may approve from there, by scope and by consequence, as the record earns it. Whatever you delegate, the agent that writes the change cannot quietly redefine what counts as done. Editing an approved requirement marks its approval stale, and any new approval is on the record with the actor and the level.
The audit work Proof does for you sits outside this dial. A person validates every finding before it reaches you.
An agent may
- propose a requirement, as a draft
- approve at any level your policy leaves open — every level, until you narrow it — recorded as the agent
- attach evidence to an obligation
- run the obligations again
- open a known issue
Only a person may
- decide which levels stay open to an agent — that setting lives in your repository and moves in a commit you review
- approve at the levels you reserve
- decide which misses from public work are published at all
Every action an agent takes is written to a log with the actor that took it. The log lives in your repository, next to the evidence, and it is readable without us. Each action in the left column runs inside your repository rather than through the hosted endpoint; section 08 draws that line. Token scope, repository boundaries, and the permission model itself are set out on the trust page.
Who checks the checker →What agents may read, propose, and approve →
07 · Your agent
Use the agent you already have.
Proof does not ship a coding agent, and it does not ask your team to replace the one it already uses.
The agent connects to the graph of your repository and keeps its own workflow, its own prompts, and its own habits. Nothing in the model belongs to a particular agent, and nothing in your repository has to be rewritten to suit one.
claude codecursoryour own tooling
Proof does not require a particular agent.
Bring any coding agent. Proof gives it the accumulated understanding of the software.
08 · Try it
Try it now. No signup. No token.
Point your coding agent at the public jsonparser graph and ask it something. Nothing is installed, nothing is registered. What the endpoint does, and what it leaves to your repository, is set out under it.
Through Proof MCP
- read requirements, with the obligations and hazards on them
- read what a requirement depends on, and what depends on it
- read known issues and findings
- read reproducers, and the tests bound to a requirement
- read change records and their history
- calculate the blast radius of a proposed change
- read and search the audited source that evidence references
- post a comment on a finding, only where the token allows it
Inside the customer repository
- propose requirement changes
- attach evidence
- run verification
- open issues
- create change records
- approve where policy allows
MCP gives the agent the model. The agent acts through the customer’s repository, CI, and permissions.
Every read carries the graph version it was answered against, so two runs a week apart can be compared.
Tool names and permission scopes are settled when Proof is installed, because they follow the shape of the repository.
The whole graph, over MCP →The methodology behind the evidence →