Findings ledger
The ledger, including the miss.
Proof is a correctness audit practice; this ledger is its public record. Two entries so far: dated, each publishing its own triage boundary, each naming its validator or saying why the name is withheld. We publish our misses, because a record that only contains wins has been edited. And no finding count will ever be a headline here; counts are the cheapest thing an audit produces.
JULY 2026 · PUBLIC AUDIT · SUBJECT: jsonparser · VALIDATOR: Leonid Bugaev
The defect that got past us.
In July 2026, a silent data-loss defect in jsonparser's Set() escaped our audit and came back through a user report. The affected code carried 100% MC/DC at the time. That is the uncomfortable part, and the reason this entry leads the ledger: coverage was complete and the defect got through anyway, because the proof had a gap. The blameless postmortem naming that exact gap is published in the repo, next to the finding and the fix, where you can re-run both.
The context. jsonparser is our founder's own library, a decade old; it went first on purpose. Formalizing its behavior produced 123 requirements, and judged against them, seven real bugs surfaced, survivors of years of production use and fuzzing. The taxonomy, the OSS-Fuzz blind spot, and the fixes live in the case study below. The register is public and live: browse it.
Validated by the maintainer, who is also our founder, which is exactly why every artifact in this entry is public.
TRIAGE BOUNDARY
In scope: the library's public API, formalized as 123 requirements. The Set() defect sat inside that boundary with full evidence attached. Nothing about the scope excuses it, which is why it counts as a miss and why it gets the postmortem.
The full case study → · the postmortem · the 123 requirements · the repository
2026 · PRIVATE ENGAGEMENT · SUBJECT: an enterprise API gateway · VALIDATOR: named in the engagement record; withheld here under the same permission rule as the client's name
One component, and the crash class every existing test missed.
The engagement scoped one component of an enterprise API gateway. The engineers who owned the component approved 47 requirements in about two hours of their time, and the audit itself changed zero production code (it reads; it does not write). Against those requirements, the audit surfaced a nil-pointer crash class that every existing test missed. The approval step alone surfaced seven undocumented design decisions the team itself disagreed about.
The client is not named because we had not asked permission when this entry shipped. We publish names only with written approval; if permission is granted, this entry will be updated.
TRIAGE BOUNDARY
In scope: one component, chosen with the client and defined by the 47 approved requirements. Nothing outside that component is claimed here.
What a single finding looks like.
Every finding in an engagement ships in this structure. A finding without a runnable reproducer that fails on the client's current main, validated by a named reviewer, does not ship.
A REAL ONE, FROM THE PUBLIC LEDGER
KI-3 · Set() / array-index path under an object parent status: fixed
expected Set writes the value at the addressed path
observed malformed JSON output on array-index paths under object parents
reproducer set_spec_test.go · // Reproduces: KI-3 · red before the fix, green since
severity our assessment, weighted by reachability and impact;
a starting point for the maintainers' triage, not a CVSS determination
evidence proof/known-issues/KI-3.yaml · evidence record
retest fixed and pinned; the reproducer stays in CI as a regression test
When the reproducer goes green on a release, the retest record is appended and the test stays in the client's CI as a regression pin.
One open-source pre-release audit per quarter, self-funded.
Coordinated with the maintainers, on their schedule. No invoice, no commercial follow-up.
Maintainers: the scoping form with “OSS audit” in the message is the application path. This ledger has to earn the right to be believed, and open source is the only place it can: a client's requirements corpus describes their product in enough detail that publishing it would publish the product; no permission fixes that. So public proof accumulates here one self-funded open-source audit at a time, and paying our own way keeps the entries free of anyone's release marketing.
Check the bar itself.
/methodology
The bar we audit against, the checks that enforce each clause, and a table of what this audit cannot see.
/continuous-correctness-audit
The engagement, its shape, and its five commitments.