Watch a promise become a test that never stops running.

— 90 seconds. scroll.

Scroll. This is the actual product, working on a real bug.

01 / 05 · The dig

jsonparser · set.gorecovered from code · history · tickets

Recovered promises

saving a value must not delete others

invalid input must not crash

results must match what was stored

func (d *Document) Set(key string, val []byte) error {
    if !json.Valid(val) {
        return ErrMalformed         // never crash on bad input
    }
    idx := d.find(key)
    d.buf = splice(d.buf, idx, val) // one key changes, siblings stay
    return d.verify(key, val)       // read back what was written
}

Your code knows what it does — not why. We dig the promises out.

02 / 05 · The contract

REQ-JP-201criteria → integration tests

When Set() writes one value, every other value survives.

Acceptance criteria

Saving preserves all other values
Malformed input returns an error, never a crash
What you read equals what you wrote

Approved before any code is judged Signed: your engineer ✓

Each promise becomes a requirement your engineers sign — with its acceptance criteria.

03 / 05 · The proof

REQ-JP-201 · formalizedFRETish · checked by solvers

“When Set() writes one value, every other value survives.”

when Set(key, value) executes, the document shall retain every sibling entry

REQ-JP-202if input is malformed, Set shall return an error

REQ-JP-203when Get follows Set, it shall return the stored value

NO CONTRADICTIONS · machine-checked ✓

Then we turn them into math — and prove no two promises contradict.

04 / 05 · The coverage

situations to cover: 14 MC/DC condition coveragehazard analysis

An illustrative grid of condition combinations fills in one by one; two rows are flagged as worst cases: silent data loss, and crash on bad input.

illustrative slicethe real answer is computed per requirement

The math tells us how many tests are enough — including the worst cases.

05 / 05 · The gate

CI · your pipeline runs on every commitpinned forever

$ go test ./...

TestRegression_MISS001 ...... FAILPASS

sibling value lost after Set() — promise broken fix landed · siblings preserved on every write

v1.1

v1.2

v1.3

v1.4

v1.5

∞forever

// Verifies: REQ-JP-201exit 1 · merge blockedevery release since · green

They run in your CI on every change. Forever.

This is a true story.

That promise comes from a real audit — a Go JSON library our founder maintained for a decade, a dependency of major cloud-native projects. It was silently losing data when saving a value into an array. The output was still valid JSON, so no test complained. A user caught it. One promise escaped even our audit — so we pinned it as a regression test and published the full postmortem.

123

promises written down and signed

real bugs found by the audit

miss, published in full

See every promise, test, and finding — the live audit portal →

What it costs

01One fixed fee, agreed before we start.
02One component — the one you worry about most.
03About four weeks, end to end.
04Then it keeps running in your CI, on every commit.
05Stop anytime. Everything we built keeps working.

the fine print, for skeptics

We make multiple excavation passes over your code, commit history, tickets, and docs — most promises were never written down anywhere else. Each requirement's acceptance criteria become integration tests in your suite. Requirements are written in FRETish notation with NASA-verified semantics, then checked for consistency, realizability, and vacuity by the Kind2 model checker and the Z3 theorem prover — before any code is judged. MC/DC condition coverage answers "how many tests are enough?" for each requirement, code is exercised to that answer across eleven languages, and every requirement carries its own hazard analysis. A 52-check audit gate holds the whole chain together on every commit.

Tell us which component keeps you up at night.

That is where we start. One component, four weeks, promises in writing.