“If I change Refund(), what could be affected?”
the map answers · three promises · four tests · one known issue, already on the path
The graph
Your codebase has a map.
The Software Intent Graph connects what your software must do to the code, hazards, checks and decisions behind it. Those obligations stay with the repository after a ticket closes. Your next agent can retrieve them through MCP, including the history and evidence it needs to check again.
promisecodetestknown issue
hover a card · its links light up
Configured checks validate recorded links when they run in your workflow. To see a map that was actually built, open the public one below.
A real one
The same map, on a public repository.
buger/jsonparser: a Go JSON parser, more than ten years in production. Its map and its register are public.
123
requirements for this project, each one a sentence you can open. 28 are approved; the other 95 are in review.
141
functions in the library, traced to the promises they serve. The tree also carries 139 generated benchmark stubs, all stamped against one stakeholder requirement, so the full count is 280. The project's changelog published 279/279 at v1.5.0, before the last function landed.
6
defects found and fixed upstream, each carrying a test you can run
2
misses published, with their postmortem. Both are defect records on the same public register
Open the live graph → seeded product demo; read the labels first See the register →
SEEDED PRODUCT DEMO Open findings on branch proof-demo are demonstrations. That capture is the probelabs/jsonparser fork. The real register is buger/jsonparser master. Draft requirements remain candidates; approval records authority for the promise. What this record does not prove →
Blast radius
Touch one function. See what needs checking.
Change one thing and the map lists what depends on it, before you merge.
One promise in the drawing above, walked to everything that depends on it. Recorded reach gives you candidates to investigate; it does not establish which behaviors changed.
Questions
Ask it, in plain words.
The map answers the questions engineers ask before a change. These are drawn on the example payments service, not a live repository.
“If I change
“Is this bug already known?”
the map answers · yes · PAY-KI-07, reproducer attached · a person validates every finding before it reaches you
“What does this component promise?”
the map answers · the list, in plain words, each line with its recorded approval and authority
The questions are real ones. Your engineers ask it. Your CI asks it when the configured CI checks run. Your agents ask it while they work.
Who approves
Agents read the map. You decide who approves it.
Your agents read the map over MCP while they work. Proposals and new evidence move through your repository and approval workflow. Approval follows the saved project policy. Current proof init templates allow agent approval at every assurance level. Configure delegation explicitly before relying on it for higher-consequence work; projects without an agent delegation policy deny agent approval.
Recommended policy: reserve higher assurance for a person.
This example requires current approval at A/B and permits agent approval at C–E. It is a supported configuration, not today’s initialization default. Keep the project’s existing role and comment requirements.
project:
approval:
required_for:
assurance_levels: [A, B]
agent_autonomous_for:
all: false
assurance_levels: [C, D, E]Approval records a decision. It does not run all checks or grant merge or deployment permission. Those transitions need their own current evidence and authority.
When code moves
Keep the obligation. Recheck its evidence.
A changed code revision, requirement or recorded evidence basis can make an earlier result unusable. Run the applicable checks and inspect which evidence is current, stale or missing. Unrecorded dependencies remain a limitation of the map.
Repairing a link restores traceability; it does not establish behavior. Renew the affected evidence, and authorize any amendment to the promise under the applicable policy. See when evidence needs to be renewed.
Start
Start with one component.
Pick the one you would least like to be asked about. The audit starts there, and the map and the gate are yours.
We scope a first use of Proof in your existing repo and agent workflow. Private code stays private. We countersign your NDA before we read a line of your code.
Prefer a call? Ask for 20 minutes →
Leonid Bugaev · founder
sets the bar, and publishes the misses from public work
Inspect a change, not just a diagram.
A retry setting changes. The old check no longer supports the promise. Follow the actual passing, failing and corrected runs, with the gaps still visible.
Explore a requirement and its evidence → · Open the runnable example → · Compare workflows →