Agents
Your agent gets the whole graph.
Proof gives coding agents the requirements, dependencies, hazards, historical defects, reproducers, and verification obligations surrounding every change. Everything this page shows is served over MCP — no signup, no token: point any MCP client at it.
01 · Read
Navigate through intent
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.
02 · Reach
Understand blast radius before editing
The agent asks what a change can reach, and gets an answer before the first edit, not after review.
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 known issue classes
03 · Evidence
Start from executable evidence
A Proof finding arrives with a reproducer, so the agent can observe the failure before it touches the implementation.
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, not what somebody remembered.
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.
- 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
Give the agent the evidence, not the bug report.
04 · Change
Create evidence-backed changes
Every feature and every fix leaves behind an evidence-backed change record.
The agent does not close its work by writing a summary. It closes it by producing what the requirement asked for: the tests, the properties, the documentation update, and the review the change needed. All of it stays attached to the intent that moved.
When a known issue is fixed and the closure is verified, Proof creates a verified defect record that preserves the fix and its evidence. A passing reproducer establishes that the known instance is gone. Closing the wider class needs the broader obligations, the sibling sweep, and the hazard evidence as well.
- Kind
- feature
- Intent
- Support nested array updates.
- Requirements
- 2 added, 3 affected
- Evidence
- 8 tests, 2 properties, hazard review
- Approved by
- a named maintainer
05 · Re-proof
Know what must be re-proven
The graph does not silently preserve yesterday's confidence. It knows what needs to be proven again.
When the agent changes 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.
So the agent is told what its own change invalidated. Done means those obligations ran again, not that the tests which already existed still pass.
06 · The assurance model
Approval follows criticality
An agent can propose a requirement. Who may approve it follows the assurance level you set.
Every requirement carries an 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.
At level A a named person approves, and the name is recorded. At level C an agent may approve its own requirement, and the record says so. Every approval names who or what approved, at which level.
The point is control. You decide what requires your judgment. An agent approving its own work is exactly what the top levels exist to catch: where the grade carries real consequence, a person gives it, by name.
An agent may
- propose a requirement, as a draft
- approve a requirement its level allows, recorded as the agent
- attach evidence to an obligation
- run the obligations again
- open a known issue
Only a person may
- set an assurance level, or move one
- approve at the levels you reserve
- decide that a miss gets published at all
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 · Architecture
Access architecture and permissions
Your agent queries the intent graph directly, over MCP, against your repository. It arrives at a read surface that is wide, an action surface that is narrow and logged, and one boundary that is neither. The interface will evolve; the shape is the commitment.
Read surface
the graph, at a stated version
- components
- requirements and their dependencies
- hazards
- obligations
- evidence, and its freshness
- known issues and reproducers
- change records and defect records
- blast radius for a proposed change
Action surface
narrower, and written to the log
- propose a requirement, as a draft
- approve a requirement its level allows
- attach evidence to an obligation
- run the obligations again
- open a known issue
Approval at the levels you reserve is not on this list. It stays with a named person.
- Graph version
- Every read is answered against a stated version of the graph, so two answers taken at different moments can be told apart.
- Evidence freshness
- Evidence is never returned as current on its own. It is returned 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.
- Audit log
- Every action an agent takes is recorded with the actor that took it. The log lives in your repository, next to the evidence, and it is readable without us.
- Approval boundary
- Approval follows the assurance level, declared per component and per requirement. At the levels you reserve, only a named person moves a draft to approved; below them an agent may approve its own draft, and the record names the agent and the level.
The exact tool names and permission scopes are settled when Proof is installed on a repository, because they follow the shape of that repository.
The whole graph, over MCP →The methodology behind the evidence →
See it run against a real repository.
One component, one change, and the answer the agent gets back before it edits anything.
seeded showcase branch; read the labels first
Request demo →