“If I change Refund(), what breaks?”
the map answers · three promises · four tests · one known issue, already on the path
The graph
Your codebase has a map.
Nobody drew the part that says what the code is for.Proof draws it from the promises your engineers approve, and a gate keeps it true.
promisecodetestknown issue
hover a card · its links light up
In a real project the gate checks every edge on it, on every commit. 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 map → seeded showcase branch; read the labels firstSee the register →
Read the labels on that portal before you read the counts. That capture is proof-demo, our showcase branch on the probelabs/jsonparser fork, not on buger/jsonparser. It carries seeded demonstration defects next to the real history, so the open entries and the severity badges on those screens are not a live defect queue; the campaign's real findings sit under Fixed, and every one of them is on the public register. Not every promise on that map is approved either. The portal prints the status on each one, and until a promise is approved nothing is judged against it. What this record does not prove →
Blast radius
Touch one function. See what moves.
Change one thing and the map lists what depends on it, before you merge. Pick a ring to see what it means for you.
One promise in the drawing above, walked to everything that depends on it. Every affected thing is listed by name, and the list is what you act on.
Questions
Ask it, in plain words.
The map answers the questions your engineers ask before they change something. Three of them, drawn on the same payments service as the map above.
“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 approved by the engineer who owns the code
The questions are real ones. Your engineers ask it. Your CI asks it on every commit. 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, and they can propose promises to it. Who approves a promise follows the assurance level you set on it: the critical ones wait for a named person, and below that line an agent may approve its own, on the record.
When code moves
The map cannot go stale unnoticed.
Code moves every day: a function is renamed, a test is deleted, a file is split in two. On the next commit the gate names the link that no longer holds, this promise, this file, this test.
Your engineers fix the link or change the promise, and the map is true again. A map inferred from the code alone drifts with every commit, and nobody is told.
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.
Private early access: we take on a small number of engagements at a time. 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