The engine came first. The public proof came next.

Proof started as a verification engine. The engine answered a pattern enterprise engineering knows well: growth means more tests, more nuance, more edge cases, and still more bugs; the test suite becomes its own scaling problem; new features ship 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, and the engine is the product. Why build it, 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.

An engine alone convinces nobody. Someone accountable has to point it at real code, judge what it finds, and publish what it missed. That is the second half of the company: the platform builds the graph, and a named assurance practice stands behind what the graph says.

We build the instruments we audit with, and the boundary is a policy: publish our evidence, keep the engine. What the engine produces for our public work lands in the open, where anyone can re-run it. What it produces for a client never lands anywhere public.

The first public audit on the register is of our own library. jsonparser, which the founder wrote and has maintained in public for ten years, went first on purpose: the audit formalized its behavior into requirements, surfaced real bugs that had survived years of production use and fuzzing, and published the misses, with postmortems, on the same register as the wins.

The flagship rsync audit followed. Two public audit efforts are on the record so far, and both catalogues are public, including the findings we later withdrew.

Leonid has spent two decades building infrastructure tools engineers run in production: GoReplay, a traffic-replay system maintained in the open for over a decade, and jsonparser, a Go JSON library that thousands of public repositories depend on. Both claims are checkable: the repositories are public, and the adoption numbers are on them, not here. He ran engineering at Tyk, an API management platform.

Findings are issued against a published bar, and their authority is a runnable reproducer. Machines check everything, every time. A person validates every finding before it reaches you: you never open a finding that nobody checked.

Names go on the promises, on the bar those promises are judged against, and on the decision that a miss gets published in public Proof work. Private engagement evidence stays private unless the customer authorizes disclosure. The published postmortem carries no personal signature, and we say so where we publish it.

What you are relying on is that bar, the engine that enforces it, and evidence that re-runs in your own repository. What you are not relying on is anyone’s day-to-day presence: the corpus re-runs in your CI without us. A named principal can only stand behind so much work, so the practice takes a limited number of engagements each quarter.

Generated claims are cheap now; checkable ones are not.

Every figure in this section is counted on Proof’s own corpus, which we do not publish. Take them as stated, not as checked: Proof runs under the same discipline it sells, with nearly two thousand requirements across four specification levels, from stakeholder intent down to integration contracts, every function annotated, zero orphan code, checked on every change the same way client work is checked.

That corpus stays private, for the same reason client corpora do: a full requirements tree describes its system completely enough to rebuild it, and this one describes the engine. The public reference is the jsonparser audit, browsable file by file.

Three of the instruments are public. They are the checkable half of the portfolio: