About

The practice.

Proof is a correctness audit practice that builds its own instruments. This page is who stands behind the signatures, and what you are actually relying on when you rely on them.

Page job: the persona and structure disclosures that were deliberately removed from the homepage live here, where a reader who wants them comes looking. The framing promise (you never depend on any one person) is made in the first breath because it is the question that brought most visitors to this page.

§ 1 · Why this practice exists

The engine came first.

Proof started as an instrument, not a practice, and the instrument started as a response to pain. Years of leading engineering at companies selling into the enterprise market taught our founder the pattern: enterprise growth meant more tests, more nuance, more edge cases, and still more bugs; the test suite became its own scaling problem; new features shipped regressions, and regressions cost reputation. The disciplines that answer this (managed requirements, formal proofs, condition-level coverage) existed, but they were locked inside regulated industry.

The engine brought them out. The practice exists because an instrument alone convinces nobody. Someone accountable has to point it at your code, judge what it finds, and sign.

Job: origin story in the practice's register, engine-first (true, and it frames the practice as the commercial surface of a technical asset rather than a consultancy that bought tools). Echoes homepage §4's provenance without repeating its sentences.

§ 2 · The founder

Leonid Bugaev

Leonid has spent two decades building infrastructure tools engineers run in production: GoReplay, a traffic-replay system used at thousands of companies, and jsonparser, one of the most widely used JSON libraries in Go. He ran engineering at Tyk, the API management platform, with official approval to build Proof alongside.

The first public audit in the ledger is of his own library, including the miss and its postmortem. He built the engine, wrote the bar it enforces, and signs against it. Why an audit practice, after two decades of building tools? Because the question that would not go away was whether anyone could prove their software did what they promised, starting with his own.

portrait photo · plus links: GitHub, GoReplay, jsonparser, the jsonparser audit entry

The credibility asset, stated as track record rather than title. No employer named (standing rule). ⚠ VERIFY with Leo: "two decades" phrasing, and which links he wants public here. The own-library-audit sentence is the bridge to /findings; it makes the bio checkable, which is the house move.

§ 3 · How the practice is built

What you are betting on, and what you are not.

Today, Proof is its founder and the engine he built. What you are betting on is his judgment. What you are not betting on is his availability: the bar he signs against is published, and the evidence corpus lives in your repo, re-running in your CI without anyone's presence. A named reviewer can only stand behind so much work, so we take a limited number of engagements each quarter.

Procurement-grade answers live on the trust page. We would rather look small than unverifiable; the market just learned what generated credentials are worth.

The structural answer to key-person risk, in accountability terms; /trust#continuity carries the procurement-grade version. The closing two sentences are the practice's smallness converted into doctrine: an explicit no-invented-team pledge that reads as integrity rather than apology, and quietly references the generated-paperwork collapse without naming anyone. ⚠ RULE FOR THIS PAGE'S FUTURE: add people only as they actually join; never testimonial-ize, never stock-photo, never list advisors who have not agreed in writing.

§ 4 · Where to go

The practice.

The engine came first.

Leonid Bugaev

What you are betting on, and what you are not.

The work speaks in three places.

The ledger

The instruments

The engagement