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.

See the register →

payments · example service · hand drawn affects implemented by implemented by implemented by implemented by verified by verified by verified by verified by PAY-KI-07 · open refund exceeded captured amount PAY-SYS-012 · approved a refund never exceeds the captured amount PAY-SYS-008 · approved a declined card is never charged twice PAY-SYS-014 · approved an idempotency key replays the same response PAY-SYS-017 · approved a capture never exceeds the authorised amount PAY-SYS-003 · approved amounts are stored in minor units PAY-SYS-025 · approved a ledger entry is written before a charge is reported PAY-SYS-021 · approved a webhook is retried with backoff for 24 hours code · go money.go code · go charge.go code · go idempotency.go code · go refund.go code · go ledger.go code · go webhook.go test · go TestMinorUnitsRounding test · go TestDeclinedCardNotRecharged test · go TestIdempotentReplay test · go TestIdempotencyKeyExpiry test · go TestRefundNeverExceedsCapture test · go TestRefundPartialTwice test · go TestCaptureWithinAuth test · go TestLedgerBeforeReport test · go TestWebhookBackoff24h test · go TestWebhookGivesUpAfter24h
payments · example service · hand drawn affects PAY-KI-07 · open refund exceeded captured amount PAY-SYS-012 · approved a refund never exceeds the captured amount PAY-SYS-014 · approved an idempotency key replays the same response PAY-SYS-008 · approved a declined card is never charged twice PAY-SYS-021 · approved a webhook is retried with backoff for 24 hours code · go refund.go test · go refund_test.go code · go idempotency.go test · go replay_test.go code · go webhook.go test · go webhook_test.go

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

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.

portal.reqproof.com/projects/jsonparser
The map of jsonparser in the Proof portal, centred on one requirement about ParseBoolean: edges out to the test files that verify it, the parser source that implements it, the README that documents it, and the parser component it belongs to.
The map of jsonparser, public, centred on one requirement: the tests that verify it, the code that implements it, the pages that document it, and the component it belongs to. Tinted to this page’s palette by a CSS filter; the portal’s own colours are different.
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

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 CHANGED THE CHANGE STARTS HERE THE WALK FOLLOWS PROMISES, CODE, TESTS AND PAGES 31 PROMISES EACH ONE APPROVED 10 IMPLEMENTATION FILES 10 FILES ON THE PATH OF YOUR CHANGE 33 TEST FILES 33 TESTS THAT MUST RUN BEFORE THIS MERGES 56 DOCUMENTATION PAGES 56 PAGES THAT WILL BE WRONG UNTIL SOMEONE FIXES THEM 130 affected, listed THE WALK ENDS · NO CYCLES
Illustration, hand drawn. One promise walked out to everything that depends on it. The rings and the walk are what Proof does; every count in it is made up for this drawing, because we have no published map version to pin one to. The counts you can check are on the register and the live map above.

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 invented payments service as the map above.

“If I change Refund(), what breaks?”

Refund() PAY-SYS-012 PAY-SYS-017 PAY-SYS-003 refund_test.go ledger_test.go capture_test.go money_test.go PAY-KI-07 · open

the map answers · three promises · four tests · one known issue, already on the path

“Is this bug already known?”

affects reproducer PAY-KI-07 · openrefund exceededcaptured amount validated by a person PAY-SYS-012 · approvedthe promise it breaks test · pins the breakrefund_payki07_test.go

the map answers · yes · PAY-KI-07, reproducer attached · a person validates every finding before it reaches you

“What does this component promise?”

componentpayments PAY-SYS-003minor units PAY-SYS-008no double charge PAY-SYS-012refund within capture PAY-SYS-014idempotent replay PAY-SYS-017capture within auth PAY-SYS-021webhook retries 24h PAY-SYS-025ledger before report each one approved by an engineer

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

Agents read the map. People approve it.

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.

DRAFT · AGENT THE AGENT CANNOT APPROVE ITS OWN WORK STILL A DRAFT APPROVED BY THE ENGINEER WHO OWNS IT PAY-SYS-012 · APPROVED IN THE GRAPH, HELD ON EVERY COMMIT
Where the line sits between what a machine decides and what a person decides is written down, and you can move it.

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. 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