Background diagram: an animated engineering schematic. Commits flow from a station labeled YOUR AGENTS on the left into a vertical gate of 179 checks at center. Most pass through and exit right toward SHIP; roughly one in twelve turns red at the gate, loops down through a REPRODUCER station, and returns to re-enter the flow fixed. Each completed fix settles as a permanent pin in a growing CORPUS lattice below the gate. A thin stream rises to a SIGNATURES station at top right, where people sign the promises and the bar. At the gate, a small readout cycles through the kinds of checks it runs: acceptance criteria as integration tests, MC/DC condition coverage, hazard worst-cases, formal consistency, and regression pins; occasionally one check flips red, is caught with a reproducer, and recovers. The page content — one opening question, a project index of receipts with expandable per-project dossiers, four answered questions, a five-stage demo, and a scoping form — is lettered onto translucent panels over this drawing. A status strip along the bottom edge counts this session's simulated commits, findings, and pins — live counts from the animation, not business claims.

YOUR AGENTSCOMMITS IN COMMITS IN — ENGINEER OR AGENT
THE GATE179 CHECKS · EXIT ≠ 0 SAME BAR — HUMAN OR AGENT
SHIPPROMISES HOLD GREEN MEANS THE PROMISES HOLD
SIGNATURESPEOPLE SIGN THE PROMISES + THE BAR THE PROMISES AND THE BAR — SIGNED BY NAME
REPRODUCERFINDING + FIX PROMPT EVERY FINDING SHIPS READY TO FIX
THE CORPUSPERMANENT PINS CLOSED CLASSES STAY CLOSED
REQPROOF — THE LIVING PROOF
DWG NO. PRF-21  ·  REV A
SCALE: ONE COMPONENT
DRAWN BY: THE AUDIT
CHECKED BY: THE GATE, EVERY COMMIT
APPROVED BY: A NAMED ENGINEER
REQUEST SCOPING SEE THE EVIDENCE
SYSTEM LIVE COMMITS 0 FINDINGS CAUGHT 0 PINS STANDING 84 THIS DRAWING'S SESSION — SIM COUNTS, NOT BUSINESS CLAIMS

PROOF — CONTINUOUS CORRECTNESS AUDIT · REQPROOF.COM

How sure are you?

READ THE DRAWING
REQUEST SCOPING SEE THE EVIDENCE

Green builds aren’t proof.
Evidence is.

Proof turns the promises your software makes into tests that run in your CI. Below: the evidence.

The Receipts

Issues we found. Fixes that shipped. Check every row.

PUBLIC WHERE THE OWNER SIGNED · DRAFT ENTRIES MARKED †
rsync † · findings
FindingAgeStatusLinks
memory safety in path handling ~20 yrs fixed, shipped ✓ report ↗PR ↗
silent data corruption on resumed transfers ~15 yrs fixed, shipped ✓ report ↗PR ↗
temp-file race ~10 yrs fixed, shipped ✓ report ↗PR ↗
jsonparser · findings
FindingScopeStatusLinks
F-001 · unguarded negative index → panic class 8 call sites closed same day, pinned ✓ register ↗
MISS-001 · silent data loss in Set() · escaped with 100% MC/DC · caught by a user 1 function + sibling sweep postmortem public ✓ postmortem ↗
123 requirements signed · full register ↗
assorted upstream † · merged PRs
ContributionStatusLinks
input-validation fix · parser hardening merged ✓ PR ↗
bounds check on length decode merged ✓ PR ↗
error-path file-handle leak fix merged ✓ PR ↗
curl-adjacent tooling † · findings
FindingStatus
protocol edge case in redirect handling fixed upstream ✓
unsafe TLS option default fixed ✓
engagement private — summary only
an embedded RTOS vendor † · findings
FindingStatus
ISR-latency promise formalized, then violated under load fixed, verified ✓
watchdog re-arm race fixed ✓
engagement private — summary only
a payments platform † · findings
FindingStatus
idempotency-key race in the retry path fixed ✓
rounding drift in currency conversion fixed ✓
engagement private — summary only
an industrial telemetry stack † · findings
FindingStatus
backpressure data loss under burst ingest fixed ✓
engagement private — summary only
your project one component, about four weeks request scoping →
† DRAFT DATA FOR DESIGN REVIEW — FINAL FACTS AND LINKS PENDING
Q.01The dig

Which of your promises has nobody ever written down?

More than you think — and a test suite cannot catch a promise nobody wrote down.

Every codebase carries obligations that live only in old tickets, commit messages, and the heads of whoever wrote them. Our agents dig those promises out of your code, its history, and its issue tracker — and your engineers approve every line, by name.

On jsonparser, the dig recovered 0 requirements: the library’s actual contract, written down and signed for the first time in its ten-year life.

123 approved · the live register
Q.02The gate

When an agent ships code at 2am, who vouches for it?

Machines check everything, every time. People sign what machines can’t.

Agent-written and human-written changes are graded by the same bar, on every commit. The gate does not negotiate and does not tire. A finding’s authority is its reproducer — a failing check anyone can re-run — not a reviewer’s glance.

People sign what no machine can: the promises — your engineers approve every requirement — the bar the code is graded against, and our mistakes, in public.

46% / 33%DEVELOPERS WHO DISTRUST AI OUTPUT VS. TRUST IT — STACK OVERFLOW SURVEY 2025
90% / 30%TEAMS USING AI TO WRITE CODE VS. TRUSTING IT — DORA 2025
same bar — human or agent
Q.03The miss

If your software silently lost data tonight, would anyone notice?

Usually not. That is exactly how we met this bug.

jsonparser’s Set() could silently lose data — no error, no crash, just a wrong result handed back as if nothing happened. A test suite ran green over it for years.

It got past our audit too: it escaped with 100% MC/DC coverage on the affected code, and a downstream user found it first. We treated the miss as a finding against ourselves — published the postmortem, added the requirement that would have caught it, swept the failure class for siblings, and pinned the fix so it can never quietly return.

MISS-001 · postmortem public

SOME SIGNATURES NEVER AUTOMATE.

Q.04The pins

The bug you fixed last year — are you sure it stayed fixed?

Under Proof, a fix is not finished when the ticket closes.

Every confirmed defect becomes a permanent pin: a reproducer that runs on every audit, forever. If the bug ever tries to come back, it is caught before it ships — not rediscovered by a customer.

And every miss is root-caused, not just patched. If one function could fail this way, the functions shaped like it are swept too, and the whole pattern is pinned. Classes of bugs go extinct. Tickets merely close.

reproducer → pin → forever

Watch a promise become a test that never stops running.

FIVE STAGES · A REAL BUG · KEEP SCROLLING

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.

Stop hoping.
Start knowing.

FIXED FEEONE COMPONENT≈4 WEEKSTHEN CONTINUOUS

Tell us which component you would least like to be asked about under oath. We reply with a confidential scoping note: what we would audit, what evidence you would hold at the end, and the fixed fee. A named human replies — not an autoresponder.

FORM PRF-21/A · SCOPING REQUEST

CONFIDENTIAL BY DEFAULT · NO CALL REQUIRED · REPLY WITHIN TWO BUSINESS DAYS

RECEIVED · FORM PRF-21/A LOGGED
A named human — not an autoresponder — replies within two business days.
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 179-check audit gate holds the whole chain together on every commit.