How it works

From code to promises to a gate.

Six steps. Each one leaves an artifact you keep.

Explore a live map →

01Recover02Sign03Worst case04Obligations05Evidence06The gate

Step 01

Recover the promises.

We read the code and write down what it promises, one sentence each, in plain words.

You keep · the promises, written down, in your repo

promises nobody wrote down written down, in plain words

Fig. 01 · Promises found in the code, written down.

Step 02

Your engineers sign them.

A promise counts only when a person who owns the code signs it.

You keep · signed promises, a name on each

the promise signed by name draft · agent waits for a person

Fig. 02 · Three signed. One agent draft waits for a person.

Step 03

Write the worst case.

For each promise, what happens if it fails, and how bad.

You keep · a worst case for every promise

the promise if it fails, how bad the worst one

Fig. 03 · A worst case per promise. The bigger diamond hurts more.

Step 04

Turn it into obligations.

What must be true, and what test shows it.

You keep · obligations, each tied to a test

what must be true the test that shows it

Fig. 04 · Under each promise, what must be true, and the test for it.

Step 05

Show the evidence.

Every obligation carries its evidence: the test that ran, and which conditions in the code it exercised.

You keep · the evidence, per condition, per commit

A B C result all three true · passes only A changed · A matters only B changed · B matters only C changed · C matters true false

Fig. 05 · Each condition is shown to matter on its own, not just that the test passed.

The formal name for this measure is MC/DC, modified condition/decision coverage.

Step 06

Hold every commit to it.

The same checks run on every change. A broken promise blocks the merge.

You keep · the gate, in your CI

your commits the gate merge a broken promise stops here

Fig. 06 · Four commits. Three pass. The broken one stops.

Who decides

Who checks the checker.

Machines check everything, every time. People decide what a machine must not decide alone.

machines people your agent writes the code the code your engineer signs the promise the promise the gate every check, every commit merge one fails a person decides here and you can move it a person validates it before it reaches you your dashboard the failing test it fails on your main

Swipe sideways to see the whole figure.

Fig. 07 · Above the line, machines run every check on every commit. Below it, people sign the promise and validate the finding.

Agents

Do the crunching: every check, every commit, at a volume no person could reach.

A person

Validates every finding before it reaches you, and signs the promises, the bar, and our misses.

Your engineers

Sign the promises. Anything an agent drafts is marked as a draft, and an agent cannot approve its own requirement.

The line between what a machine decides and what a person decides is written into the configuration, and you can move it.

After a fix

The test stays.

When a break is fixed, its test stays. The class cannot come back without the gate saying so.

one class of break seen in three releases the test stays no recurrence since 123 456 789 10 ten consecutive releases a test for it no test exists the test runs on every commit

Swipe sideways to see all ten releases.

Fig. 08 · One class of break, ten releases. Once its test is in your suite, the release that would bring it back turns the gate red instead.

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 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 promises, the bar, and the misses