Proof · a record of what your software promises

Prove your software does what you promised.

Proof writes down the promises in your code. Your engineers sign them. A gate checks every commit against them.We find each point where your code breaks a promise. We give you the test that fails.

Request a demo

Open a live map →

public on buger/jsonparser123 promises signed7 breaks fixed upstream1 miss published

example · a payments service promisecodetestknown issue affects implemented by implemented by implemented by implemented by verified by verified by verified by verified by verified by SYS-REQ-011 · SIGNED amounts are stored in minor units SYS-REQ-012 · SIGNED a refund never exceeds the captured amount SYS-REQ-018 · SIGNED an idempotency key replays the same response SYS-REQ-023 · SIGNED a webhook is retried with backoff for 24 hours SYS-REQ-031 · SIGNED a declined card is never charged twice code · go refund.go commit code · go idempotency.go code · go webhook.go code · go charge.go test · go TestAmountsInMinorUnits test · go TestRefundNeverExceedsCapture test · go TestIdempotentReplay test · go TestWebhookRetryBackoff test · go TestDeclinedCardNotRecharged --- FAIL: TestRefundNeverExceedsCapture KI-07 · OPEN refund exceeded captured amount validated by a person register example · payments affects SYS-REQ-011 · SIGNED amounts are stored in minor units SYS-REQ-012 · SIGNED a refund never exceeds the captured amount SYS-REQ-018 · SIGNED an idempotency key replays the same response code · go refund.go commit test · go TestAmountsIn MinorUnits test · go TestRefundNever ExceedsCapture test · go TestIdempotent Replay KI-07 · OPEN refund exceeded captured amount validated by a person register

A commit changes refund.go. The map shows the promises of that file.

Public receipt

What Proof found on a real repository.

buger/jsonparser is a Go JSON parser with 5,600 stars and ten years of use. All data below is public. You can run each check again.

portal.reqproof.com/projects/jsonparser
The live map of jsonparser: a known-issue card on the left, the three requirement cards it affects in the middle, and the test files and code files that verify and implement them on the right, joined by labelled edges.
The live map of jsonparser, with one known issue at the centre. The map shows the promise it breaks, the code that implements that promise, and the tests that check it.
123

promises signed by the maintainer

7

breaks fixed upstream. Each break has a test that failed on main

1

miss published, MISS-001

KI-3: Set() could remove a sibling value on an array-index path under an object parent. The promise says: replace one value, and change nothing else. The test that failed on main is in the register. The test stays there.

The finding

A promise breaks. You get the test.

A finding is a test that fails on your main branch. The broken promise is attached. You run the test and see it fail. You apply the fix and see it pass.

01 · said, in plain words Set() replaces one value, nothing else. the promise, in one sentence 02 · signed A requirement, signed by the maintainer. the promise now exists outside the code 03 · broken A test that fails on main. set_spec_test.go · Reproduces: KI-3 a person validates it before it reaches you 04 · fixed upstream A pull request, merged. the same test passes on the merge commit 05 · the test stays In the suite, on every commit after. removing it fails the gate

Fig. 01 · One finding, from start to end. The test stays in your suite. This class of break cannot return without a gate failure.

What you keep

What you keep.

Four artifacts. They stay in your repository, under your licence.

01

The promises, written down and signed

We recover every promise of your component from the code. Your engineers sign each one.

02

A register of known breaks

Each break has a test that fails on your current main. A person validates each break before you see it.

03

A map you can ask

Select a function or a promise. The map shows what else changes. Your engineers, your CI, and your agents use the same map.

04

A gate on every commit

The gate reads the map on each change. A broken promise stops the merge.

If we stop work tomorrow, your map, your gate, and your register continue to operate.

The map

Touch one function. See what moves.

You can see the effects of a change before you merge it.

the promise a refund never exceeds the captured amount written in a design doc nothing checks it this component every service on that path every customer at once blast radius your ci green every test you already have, passing the promise a refund never exceeds the captured amount written in a design doc nothing checks it this component every service on that path every customer at once your ci green every test you already have, passing

Fig. 02 · The blast radius of one promise that is not written down. Example. The promise is only in a document. No check can fail on it. The failure occurs at your customers.

How the map works →

Accountability

Who checks the checker.

Machines check everything, every time. People decide what a machine must not decide alone. This limit is written in the configuration. You can move it.

Agents

Run every check, on every commit. The quantity is more than a person can read.

A person

One person validates each finding before it reaches you. People sign the promises, the bar, and our misses.

Your engineers

Sign the promises. Each item an agent writes has a draft mark. An agent cannot approve its own requirement.

1 · counted against code ci green every line your tests touch, executed 2 · counted against the promises ci green covered by a test that can fail promises no test can fail on 1 · counted against code ci green every line your tests touch, executed 2 · counted against the promises ci green a test that can fail promises no test can fail on

Fig. 03 · CI is green in the two pictures. The second picture is possible only after the promises are written down.

Who it is for

Who this helps first.

The CTO who signs releases

“We ship ten times faster now. Review speed did not increase ten times. I approve releases that I cannot examine myself.”

What Proof gives you: a map and a gate that you keep. The gate held the release to its promises before you sign it.

The engineer sent to check us

“I open the register and search for bad work.”

What Proof gives you: a live map, a published miss, and tests that fail on main. Run the tests again. Then tell your CTO.

The platform owner

“One bug in routing, auth, or billing touches every customer at the same time.”

What Proof gives you: the shared path as signed promises. A break on that path is a test that fails.

The engineer who ships with agents

“My agents write most of the code now. I need a record that they must obey.”

What Proof gives you: a written record of the promises in the code. Agents can read the record. Agents cannot approve the record.

Start

Start with one component.

Select the component that worries you most. We onboard it with your engineers. Then the map and the gate are yours.

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.

Do you prefer a call? 20 minutes with Leonid →

Leonid Bugaev · founder
signs the bar and the published misses