Carlos Toledo
Methods · audit · 14 August 2026

An independent audit of OpenAI’s ten-proofs

On 1 August 2026 OpenAI published Ten Advances in Mathematics and Theoretical Computer Science — 253 pages, author “OpenAI,” no human names — with a Lean repository holding its entire verification story. This page reports an independent audit of that repository, unaffiliated with OpenAI: the tree built at its pinned commit, every claimed declaration checked through the kernel, the repository’s own cross-kernel audit protocol executed, all twelve challenge statements read against the manuscript’s theorems, and the week-one revision diffed against the original. The one-sentence result: at challenge level, we found no place where the machine-checked statement is weaker than the paper’s claim — every discrepancy we found there runs the other way — and the precise list of what that does and does not establish is the last section of this page.

The object, at pinned bytes

objectpin
manuscript (6 Aug revision)cdn.openai.com/pdf/ten-proofs-oai.pdf · sha256 ebc561ab…3638f8c566
manuscript (1 Aug original)…/ten-proofs-oai-original.pdf · sha256 64b900d5…5898ac7dd6
Lean repositoryopenai/ten-proofs @ 94bc0feb6a9ff12c7d31d6de640a725c9d43d2b6 (its only public commit)
toolchain / mathlibleanprover/lean4:v4.32.0 (the repo’s own file) · mathlib 81a5d257… (lake-manifest)

The repository is 548,215 lines of Lean in ten chapter files, a twelve-entry formalization.yaml, and twelve Comparator challenge files. The PDF contains no verification appendix; the manuscript and its formal counterpart meet only through declaration names. That correspondence is what an audit can check, and it is what this one checked.

Build, kernel, axioms

lake build All at the pin: Build completed successfully (8666 jobs), exit 0, on a 16 GB laptop, mathlib from the community cache. A prior public build attempt deserves its credit here: Curtis Pyke (kingy.ai, 1 August) built most of the tree first-hand within a day of release, stopped short of completion when his local task runner terminated the process, and wrote plainly that his check “is not an independent proof audit.” His counts (8,820 of 9,007 jobs compiled) sit beside ours (8,666 completed); the runs used different targets and toolchain states, and we report all three numbers rather than reconcile them.

#print axioms through the built environment, for all twelve declarations named in formalization.yaml: every one depends on exactly [propext, Classical.choice, Quot.sound] — the minimal classical base — with no sorryAx, no native_decide axiom, nothing else. A tree-wide sweep found zero escape hatches — no sorry, no admit, no unsafe, no @[implemented_by], no axiom declarations — in 548K lines, outside the challenge statement files, which carry sorry by design (they are the statements Comparator matches proofs against). And two theorems the manifest never mentions check to the same three axioms — more on those below, because they are the audit’s most interesting class of finding.

The ten advances, one by one

Each advance, its claim in one line, and this audit’s verdicts as tags. green = a check that ran and passed · teal = the machine-checked statement is stronger than the paper’s claim · slate = a referee note · oxblood = a finding that needs attention. “cross-kernel” means the shipped Comparator challenge passed both the Lean kernel and nanoda; “faithful” means the challenge statement matches the paper’s theorem at statement level.

Score at a glance: ten of ten build and kernel-check to the minimal classical base; twelve of twelve shipped challenges pass both kernels; the attention items are chapter 3’s seam, chapter 5’s unchallenged headline, and chapter 2’s shared priority. The sections below carry the detail behind every tag.

The repository’s own audit protocol, executed

The repo ships twelve challenge configurations for Comparator, the Lean FRO’s cross-kernel proof judge: each pins the exact statements, permits exactly the three classical axioms, and enables nanoda — an independent second kernel — alongside Lean’s. Comparator’s sandbox (landrun) requires the Linux Landlock LSM, so these runs executed on fresh single-use Linux VMs, with the Landlock probe as the first step of every job and every tool’s commit recorded in every log.

One configuration observation, credited where it belongs: the repository pins a Comparator from one merge before the fix in comparator PR #60 (merged 31 July 2026 — before the manuscript’s release), which inserts the -- terminator that current landrun’s CLI otherwise consumes. Followed exactly as shipped — the pinned manifest plus Comparator’s instruction to build landrun from main — every challenge fails before reaching the mathematics, with the same symptom PR #60 fixed. The mechanism and fix are upstream’s — matteo-ax’s, by that PR — not ours; our contribution is only the measurement that the shipped pin predates it, and the workaround (build landrun at its pre-cli-v3 commit, or bump Comparator past the fix) that makes the shipped protocol runnable.

The verdicts: eleven of the twelve challenges — sphere packing, binary codes, spherical codes, the permanent formula bounds, the non-sofic existence, Connes rigidity, Ehrhart, quantum parallel repetition, Ramsey, and both chapter-10 counterexamples — completed with “Your solution is okay!” and exit 0 under the hardened invocation from Comparator’s README: per its contract, each proves the same statements as the challenge files, uses no more than the three permitted axioms, and is accepted by both the Lean kernel and nanoda. The twelfth (GapCVP) is the tree’s largest module, and its run failed in three hosted configurations — an oom-kill at 7.0 GB inside the hardening scope, a VM shutdown under swap, and a rebuild-forcing trace mismatch when pre-built artifacts were seeded (the rebuild then re-hitting the same memory ceiling). Its checks therefore ran on a 16 GB machine of ours, through Comparator’s own COMPARATOR_LANDRUN environment hook, with the sandbox replaced by a flag-compatible passthrough — a deviation the run log itself records, and a defensible one: the sandbox’s threat model is an adversarial solution build, and nothing was built there beyond artifacts we had already built ourselves. Result: nanoda accepts; the Lean kernel accepts; “Your solution is okay!” Twelve of twelve.

Every log carries its environment record — tool commits, kernel, LSM list, toolchain, UTC date — and the one macOS log additionally records the passthrough and one replaced foreign-platform binary, so the deviations are in the artifact, not in a footnote.

Statement faithfulness: no weakening found — and two patterns the other way

All twelve challenge statements were read in full against the manuscript’s own theorem statements and definitions. The traps a referee would look for do not fire. Chapter 2’s challenge pins strict inequality against the fully optimized second MRRW bound for every distance — the exact trap the chapter itself warns about (“improving M₁ alone need not improve M₂”) — and decomposes the theorem’s chain faithfully. Chapter 7 defines NP and polynomial-time reductions via mathlib’s actual Turing-machine machinery inside the trusted statement. Chapter 6’s entangled value is the genuine finite-dimensional supremum, and the boundedness lemmas that keep its suprema honest (winProbability_le_one, entangledValue_le_one) are present and kernel-checked with the module. Chapter 8’s hypotheses map one-for-one onto measure-theoretic definitions. No published statement-level comparison of this repository was located — a documented search, stated with its limits in the closing section; the question itself had been posed publicly.

The discrepancies we did find run in the repository’s favor, in two systematic patterns:

Chapter 3 deserves its own sentence, because it is the sharpest seam we found: the chapter’s stated Theorem 1.1 (“the unit group LF₂(1,2)× is not sofic”) is not the pinned Lean statement, and the pinned Lean statement is not stated in the paper. Neither object is wrong; their correspondence is asserted by nothing but proximity. That is precisely the kind of gap a verification appendix would close, and this manuscript has none.

The week the humans wrote back

The 6 August revision (the original is preserved at a public URL — an auditable diff pair, and no published analysis of it was located) was not cosmetic. It added the table of contents; strengthened attribution in the front abstract — Kun, Kun–Thom, and Thompson’s group V named where the original said only “property-(T) expanders”; added citations (Cohn–Miller in chapter 1, Fujita in chapter 8, and a clarification of Connes’s original formulation credited — in chapter 4’s own acknowledgments — to Ionuţ Chifan); restructured chapter 3’s proof, replacing a multi-page expander-repair argument; and quietly inserted the word “infinite” into the stated hypothesis of the cited Kun–Thom theorem. We fetched the source: Kun–Thom’s own Theorem 1.1 reads “countable Kazhdan group,” with no infiniteness clause — the added hypothesis is harmless if the group it is applied to is infinite there — plausible, as that group is Thompson’s V — but it is not textually sourced.

The traffic ran both ways, and this is the part of the story we located nowhere else. Kun and Thom posted their own revision on 4 August — their v3’s preface says the paper was finished in mid-July 2026, and continues: “On August 1, 2026, we learned about the breakthrough result of OpenAI. The proof of their key Proposition 2.3 in [20] is a creative and effective application of the results and techniques of this paper and the ones in [18].” Chapter 4’s revised acknowledgments disclose independent concurrent work by Shuoxing Zhou on Connes rigidity. And on 10 August, Alrabiah and Guruswami posted an improvement of the same two 1977 binary-code bounds by an entirely different method, writing: “Concurrent work by OpenAI also improves the first and second MRRW bounds, albeit using a different approach” — and, separately, that the quantitative improvements to the first bound “match,” with the second-bound improvement “captured by our framework” (quotes from the paper’s HTML body). The manuscript’s dated priority claims check out at their sources — the intervening sphere-packing literature calls its own gains constant-factor in its own abstracts — but chapter 2’s “first improvements since 1977” is now a shared first, human and machine arriving nine days apart.

What the repository discloses that the manuscript does not

The PDF’s entire methodology disclosure is “an internal OpenAI model.” The repository’s formalization.yaml says more: model “Astra (OpenAI)”, framework “Codex”, wall time “1 week”, review status “agent-reviewed” — not human-reviewed. The repository has issues disabled, zero pull requests ever, and six forks, none carrying an independent commit; its repository object dates to 5 August, and its single commit is authored 2 August 2026 under a human name — Boris Alexeev — with the one-character commit message “.” (public commit metadata, read from the GitHub API). The manuscript names no humans; the repository, read closely, names one. Whatever conversation this work deserves is not currently happening on the artifact itself.

What this audit does not establish

Kernel-clean is not theorem-true-as-you-read-it: a correct kernel checking a faithfully-stated theorem is strong evidence, not omniscience, and the English-to-Lean correspondence is exactly the layer where chapter 3’s seam lives. This audit did not review the mathematics beyond the kernel, did not read most of the 253 pages’ proof bodies, and cannot audit how the results were produced — one sentence of methodology is not auditable. Two definitional choices are flagged for referees rather than resolved (chapter 4’s normality-via-projection-suprema; chapter 1’s fixed-universe property-(T) idiom), and two textual residues remain unread (one displayed formula in chapter 2’s source; the internals of chapter 3’s Proposition 2.3). We are not aware of any published end-to-end execution of the repository’s Comparator protocol, any published statement-by-statement comparison of the twelve challenge statements against the manuscript, or any published analysis of the 1→6 August revision, prior to this page; that is a documented search (fourteen logged queries, eleven fetches attempted and ten succeeded, on 14 August 2026, including the repository’s disabled issue tracker, its six forks, both tool trackers, and the Hacker News thread — not the Lean Zulip, X, or mailing lists), not a proof of absence, and one prior publication found by anyone falsifies it. Corrections are wanted and are published, dated, in the errata.

site/technical-reports/ten-proofs-audit.html · born 2026-08-14 · every number on this page is a dated record from a pinned measurement, not a live readout · no external fonts, scripts, stylesheets or images; the one script is same-origin, cookieless page counting · text CC‑BY 4.0