Proof. Request a demo

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 sign, and a gate keeps it true.

Request a demo

See the register →

payments · example service affects implemented by implemented by implemented by implemented by verified by verified by verified by verified by KI-07 · open refund exceeded captured amount SYS-REQ-012 · signed a refund never exceeds the captured amount SYS-REQ-008 · signed a declined card is never charged twice SYS-REQ-014 · signed an idempotency key replays the same response SYS-REQ-017 · signed a capture never exceeds the authorised amount SYS-REQ-003 · signed amounts are stored in minor units SYS-REQ-025 · signed a ledger entry is written before a charge is reported SYS-REQ-021 · signed 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 affects KI-07 · open refund exceeded captured amount SYS-REQ-012 · signed a refund never exceeds the captured amount SYS-REQ-014 · signed an idempotency key replays the same response SYS-REQ-008 · signed a declined card is never charged twice SYS-REQ-021 · signed 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. Every edge is a machine-checked link, not a guess.

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 live map of jsonparser in the Proof portal, centred on one known issue: red edges to the promises it affects, blue edges from those promises to the tests that verify them and the code files that implement them.
The live map of jsonparser, public, centred on one known issue: the promises it touches, the code that implements them, the tests that check them.
123

promises signed by the maintainer

279

functions, every one traced to the promises it serves

7

breaks fixed upstream, each with a test that failed on main

1

miss published, MISS-001, with its postmortem

Open the live map →See the register →

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 SIGNED 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
Measured on our own engine's map, for one promise. Every mark is a real count.

One promise on our own engine's map, walked to everything that depends on it. 130 things, each one listed by name.

Questions

Ask it, in plain words.

The map answers the questions your engineers ask before they change something. Three of them, on the example service.

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

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

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

“Is this bug already known?”

affects reproducer KI-07 · openrefund exceededcaptured amount validated by a person SYS-REQ-012 · signedthe promise it breaks test · fails on mainrefund_ki07_test.go

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

“What does this component promise?”

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

the map answers · the list, in plain words, each line signed by an engineer who owns the code

Your engineers ask it. Your CI asks it on every commit. Your agents ask it while they work.

Who signs

Agents read the map. People sign 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 SIGNED BY THE ENGINEER WHO OWNS IT SYS-REQ-012 · SIGNED 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.

Request a demo How onboarding works →

Private early access: we onboard a small number of teams each month. 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
signs the bar and the published misses