“If I change Refund(), what breaks?”
the map answers · three promises · four tests · one known issue, already on the path
The graph
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
Example service, hand drawn. The codebase, the promises, the files and the tests are invented for this drawing, so nothing here was checked. 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
buger/jsonparser: a Go JSON parser, more than ten years in production. Its map and its register are public.

requirements for this project, each one a sentence you can open. 28 are approved; the other 95 are in review.
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.
defects found and fixed upstream, each carrying a test you can run
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
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
The map answers the questions your engineers ask before they change something. Three of them, drawn on the same invented payments service as the map above.
Refund(), what breaks?”the map answers · three promises · four tests · one known issue, already on the path
the map answers · yes · PAY-KI-07, reproducer attached · a person validates every finding before it reaches you
the map answers · the list, in plain words, each line approved by the engineer who owns the code
Example service, hand drawn. The questions are real ones. The repository, the promises and the answers on these three cards are invented. Your engineers ask it. Your CI asks it on every commit. Your agents ask it while they work.
Who approves
Your agents read the map while they work, and they can propose promises to it. Anything an agent writes is a draft: it cannot approve its own work.
When code moves
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
Pick the one you would least like to be asked about. We onboard it with your engineers, then the map and the gate are yours.
Private early access: we take on a small number of engagements at a time. Leonid onboards each team himself. Private code stays private. We countersign your NDA before we read a line of your code.
Prefer a call? 20 minutes with Leonid →
Leonid Bugaev · founder
sets the bar, and publishes the misses