"Lean-checked" means a proof was written in the Lean proof language and accepted by Lean's kernel, a small program that re-checks every step against the definitions, earlier theorems and axioms the proof is allowed to use. It certifies the formal statement written in Lean, not the English paper around it. In OpenAI's 2026 collection of AI-generated mathematics, 242 of 372 result families have a Lean formalization. All 416 of the collection's Comparator checks allow only Lean's 3 standard axioms, and 80 of the formalization notes say part of the paper is outside the formal statement.
This page explains what a Lean check proves and what it leaves open. It walks through the four levels of checking in Lean's own guide, gives a checklist for any "Lean-verified" claim and works one result through it: #247, an infinite finitely presented periodic group. It ends with a tracker of all 372 results, read from the repository files at commit 1581d4c (2026-10-12).
What Lean is
Lean 4 is a programming language that doubles as a proof assistant. You write a theorem statement and a proof, and Lean checks that the proof really establishes the statement. Proofs are usually written with tactics, small programs such as decide, ring or simp that build the detailed proof for you. Whatever the tactics produce, the finished proof is handed to the kernel, the part of Lean that does the final check. A mistake in a tactic therefore produces an error rather than a false theorem. Lean's reference manual lists "honest bugs in meta-programs and tactics" among the things even the most basic check protects against.
Most serious work builds on Mathlib, the community library of formalized mathematics. It is the first library listed in OpenAI's formalization catalogue, which orders them by how often the project imports them.
The smallest possible example:
example : 1 + 2 = 3 := by decide -- accepted: Lean works it out and agrees
example : 1 + 2 = 4 := by decide -- error: the statement is false, so no proof is produced
example : 1 + 2 = 4 := by sorry -- warning: declaration uses `sorry` (nothing is proved)
A real proof works the same way with thousands of steps instead of one. Every step must follow from what came before, or the file does not check.
sorry: the placeholder that can "prove" anything
sorry stands in for a proof you have not written yet. Lean accepts the file but warns declaration uses `sorry` (before Lean 4.28 the quotes were straight: declaration uses 'sorry'); the error page covers both. Behind the scenes sorry uses an axiom called sorryAx, which the Lean reference manual says "can be used to prove anything" and is "not intended to occur in finished proofs". A theorem that depends on sorry, directly or through anything it uses, is not proved.
The manual adds a trap worth knowing. The blue double check marks that the Lean editor shows next to a finished theorem "appear even when there are explicit uses of sorry or incomplete proofs in the dependencies". A tick next to the headline theorem is not enough on its own. You have to list its axioms, as described next.
sorry: a Comparator challenge file. It states the theorem with sorry as its proof because its only job is to say what must be proved. The proof lives in a separate solution file. Seeing sorry in a challenge file is not a sign the proof is missing.Axioms: what a proof is allowed to assume
Every proof rests on axioms, statements accepted without proof. Running #print axioms theoremName lists every axiom a theorem depends on, including through the theorems it uses. The Lean reference manual says how to read the list:
| Axiom reported by #print axioms | What it means |
|---|---|
propext, Quot.sound, Classical.choice | The 3 standard axioms of Lean's logic: propositional extensionality, the quotient construction and a choice principle. The manual calls them "benign". |
sorryAx | The theorem or something it depends on uses sorry or is otherwise incomplete. Not proved. |
A name containing _native | Native evaluation was used (for example by native_decide), so the proof also trusts Lean's compiler, not just the kernel. |
| Any other name | A custom axiom declared by the author. The theorem is only valid if that axiom is true. |
The part no checker does: does the statement say what the paper says?
Lean's guide separates two questions: "does the theorem have a valid proof" and "what does the theorem statement mean". The kernel answers only the first. If a definition in the statement is subtly wrong, Lean will faithfully verify a proof of the wrong thing. The guide warns that a statement's referenced definitions "must be investigated carefully, in particular with regard to custom notation and type classes."
The Comparator documentation gives a blunt example. Suppose a challenge leaves a definition open for the solver to fill in (a definition hole) and asks for a proof that RiemannHypothesis ↔ ChallengeSolution. A solver could define ChallengeSolution as RiemannHypothesis itself and prove the equivalence in one line, which settles nothing. Comparator's rule is that definition-hole solutions "must always be checked with an additional (potentially human) verifier." In OpenAI's collection, 9 results use definition holes. One is #158, "The Euclidean plane cannot be colored with five colors", whose check leaves the meaning of ProperColoring to the solution.
The other gap is scope: a formal statement often covers only part of a paper. Two examples from OpenAI's own notes:
- #179, circulant Hadamard and Barker sequences. The circulant Hadamard classification (orders 1 and 4 only) is formalized, and so are the even Barker lengths (2 and 4). The odd Barker lengths are "outside this selected additional statement".
- #017, the irrationality exponent of π is 2. The exponent is formalized; the paper's consequence for the Flint–Hills series is outside it.
Lean's four levels of checking
The Lean reference manual's chapter "Validating a Lean Proof" sets out an escalating series of checks. Each one also catches everything the levels above it catch:
| Level | What you do | What it adds |
|---|---|---|
| 1. Blue check marks | See the double tick in the editor, or run lake build with no errors or warnings | Catches incomplete proofs, an explicit sorry in the theorem itself and honest tactic bugs |
| 2. Print axioms | #print axioms and confirm only the 3 standard axioms appear | Catches sorry and incomplete proofs in dependencies, and custom axioms |
| 3. lean4checker | lean4checker --fresh on the built module | Replays the stored proofs through the kernel; catches bugs in Lean's handling of the kernel's state, and meta-programs that bypass it |
| 4. Gold standard | Judge the proof with Comparator, external checkers enabled | Sandboxed build, statement matched against a trusted challenge; catches deliberately misleading proofs and bugs not shared by every checker |
The guide reserves the gold standard for "high risk scenarios (proof marketplaces, high-reward proof competitions, unaligned AI)". Its definition of a possibly malicious proof explicitly "includes un-reviewed AI-generated proofs and programs". Even the gold standard still assumes the soundness of Lean's logic, a correct Comparator, a secure sandbox, no bug shared by every checker and "no human error or misleading presentation of the theorem statement in the trusted challenge file."
How a Comparator check works
Comparator, from the Lean developers, is "a trustworthy judge for Lean proofs". A check has three parts:
- A challenge file, written by someone you trust, that states each theorem (with
sorryas its proof) and every definition the statement uses. - A solution file from whoever claims the proof, restating the same theorem with a real proof.
- A small JSON config naming the theorems, the permitted axioms, any definition holes and any extra kernels.
Comparator builds the solution in a sandbox and exports the finished proofs. It then re-checks them outside the sandbox. If it succeeds, each listed theorem is guaranteed to prove the same statement as the challenge, use no axioms beyond the permitted list, and be accepted by the Lean kernel. Comparator can also run nanoda, an independent kernel written in Rust, so that a bug in one kernel is not enough to pass.
OpenAI publishes 416 such configs. All of them permit exactly propext, Quot.sound and Classical.choice. 2 results enable the second kernel; the rest rely on Lean's kernel alone, one step short of the guide's gold standard. Anyone can add nanoda when re-running them.
Worked example: #247, an infinite finitely presented periodic group
The finitely presented Burnside question asks whether a group built from finitely many generators and relations, in which every element has finite order, must be finite. OpenAI's paper of 23 September 2026 says no. It builds a counterexample: a Steinberg group, St12(R), over an algebra R of characteristic two. Here is the end of the challenge file lean/ComparatorChallenges/PeriodicGroup.lean, quoted from the repository (Apache-2.0):
def Periodic (G : Type u) [Group G] : Prop := ∀ g : G, ∃ m : ℕ, 0 < m ∧ g ^ m = 1
def BurnsideStatement : Prop :=
∃ (G : Type) (_ : Group G), Infinite G ∧ Group.IsFinitelyPresented G ∧ Periodic G
theorem thm_main : MainStatement ∧ BurnsideStatement := by
sorry
Running it through the checklist below:
- The statement says what the paper claims.
BurnsideStatementasks for a group that is infinite, finitely presented and periodic.InfiniteandGroup.IsFinitelyPresentedcome from Mathlib.Periodicis defined right in the file, in one line: every elementghas somem > 0withgm = 1. That matches the scope note: "each element has some finite order; no common exponent is asserted."MainStatementpins the witness to the Steinberg group St12(R) over an algebra overZMod 2. - The
sorryis expected. This is the challenge. The proof is the solution moduleOAI.GroupTheory.PeriodicGroups.Main, wherethm_mainis stated again with a proof. Comparator's job is to confirm the two statements match. - Axioms. The config
PeriodicGroup.jsonpermits only the 3 standard axioms. - Definition holes. None:
definition_namesis empty, so every definition in the statement is fixed in the challenge. - Kernels.
enable_nanodais false, so the published check uses Lean's kernel only. - Scope. The note covers the periodic-group result. It says the paper's "separate nil-algebra and radical-algebra conclusions are outside these selected statements". The family's title also names a 5 October companion paper (a residually finite 2-group). The scope note links only the 23 September paper, and "residually finite" does not appear in the formal statement.
- Reproduction and review. The repository publishes the check, not a log of an independent re-run. Its formalization catalogue lists the review status as "unchecked".
Verdict: this is a well-specified, checkable claim. The statement is short enough to read in full, it has no definition holes and it uses only standard axioms. The main Burnside result is as solid as a Comparator run makes it. The companion paper and the algebra conclusions are not covered by this check.
A checklist for any "Lean-verified" claim
- Find the formal statement. No Lean file, no Lean check. "Formalization in progress" is not a check.
- Read the statement and every definition it uses. Look for definitions written in the same file, custom notation and anything that makes the claim weaker than the paper's.
- Look for definition holes. If the solver gets to define part of the statement, a person has to confirm the definition means what it should.
- Search for
sorryin the proof and everything it imports from the project (the challenge file excepted). - Print the axioms. Only
propext,Quot.soundandClassical.choiceshould appear. - Check which kernels ran. Lean's kernel alone, or a second independent checker such as nanoda as well.
- Check the scope. Which of the paper's theorems are formalized and which are "outside the selected statement"?
- Check it was re-run. A published config shows how to check the claim. Someone still has to run it, ideally someone other than the author.
- Check human review. Has a mathematician confirmed that the formal statement matches the published claim?
Verification tracker: all 372 OpenAI results
Each row is one result family from github.com/openai/math, read by script from the repository at commit 1581d4c (2026-10-12). Titles link to the Lean scope note where one exists, otherwise to the first paper.
How to read the columns: Lean: Yes means the repository has a scope note and published Comparator checks for that result; it does not mean we re-ran them. Part of the paper not formalized is our reading of the scope note's wording, so follow the link for the exact text. Supporting result only marks checks the repository says "verify supporting results, not the corresponding papers' main theorems". A row with no Lean formalization is the model's claim alone; the README itself warns that "some of the unformalized results could have issues."
What the numbers do and do not say
The README says about 42% of "top-line results" are formalized, while 242 of 372 families (65%) have a Lean scope note. The repository does not explain the difference, so we report both figures rather than pick one.
According to the README, the papers came from an unreleased internal OpenAI model. About 4,000 problems were posed, and each result used about three hours of ChatGPT Pro thinking compute on average. Two pieces of work followed a different procedure, and one write-up was human-edited for readability. The formalization catalogue lists its automation method as "agent" and its review status as "unchecked", and the README does not describe peer review. Formalization lowers the risk of a wrong proof sharply. Whether a formal statement says what the paper claims is still a question for mathematicians to settle.
Sources
- lean-lang.org, The Lean Language Reference, "Validating a Lean Proof" (accessed 2026-10-13) — lean-lang.org/doc/reference/latest/ValidatingProofs/. The four check levels, the reading of
#print axioms, the blue-tick caveat, and the "malicious" category including un-reviewed AI-generated proofs. - lean-lang.org, The Lean Language Reference, "Axioms" (accessed 2026-10-13) — lean-lang.org/doc/reference/latest/Axioms/.
sorryAxand native evaluation. - Avigad, de Moura, Kong, Ullrich, Theorem Proving in Lean 4, chapters "Axioms and Computation" and "Tactics" — lean-lang.org/theorem_proving_in_lean4/. The three standard axioms and the "declaration uses 'sorry'" warning.
- Lean developers, Comparator README — github.com/leanprover/comparator. Challenge and solution files, the three guarantees, definition holes, nanoda.
- OpenAI, openai/math repository at commit 1581d4c (2026-10-12) — github.com/openai/math: README.md, CONTENTS.md,
lean/formalization.yaml,lean/docs/,lean/ComparatorChallenges/(includingPeriodicGroup.lean,PeriodicGroup.jsonand its README). - OpenAI, An infinite finitely presented periodic group, preprint, 23 September 2026 — paper.pdf.
Frequently asked questions
What does "Lean-checked" mean?
It means the Lean kernel accepted a proof of the theorem statement as written in Lean, following only from the definitions, theorems and axioms in the file and its imports. It does not confirm that the Lean statement says the same thing as the English paper; a person has to read the statement and its definitions for that.
Does a sorry in a Lean file mean the proof is wrong?
It means that step is not proved. Lean warns "declaration uses `sorry`" ("declaration uses 'sorry'" before Lean 4.28), and the sorryAx axiom behind it can prove anything, so a theorem that depends on sorry is unproved. The exception is a Comparator challenge file: it states the theorem with sorry on purpose, and the proof lives in a separate solution file.
Which axioms are acceptable in a Lean proof?
Lean's reference manual calls propext, Classical.choice and Quot.sound the standard, benign axioms. If #print axioms also lists sorryAx, the proof is incomplete; a name containing _native means native evaluation was trusted; any other axiom was declared by the author, and the theorem only holds if that axiom is true.
How many of OpenAI's 2026 math results are Lean-checked?
At repository commit 1581d4c (2026-10-12), 242 of the 372 result families had a Lean formalization page and published Comparator checks, while the README says about 42% of top-line results are formalized. All 416 checks allow only the three standard axioms, 80 scope pages say part of the paper is not formalized, and the catalogue lists its review status as "unchecked".
Is a Lean-checked AI result accepted mathematics?
Not on its own. A Lean check is strong evidence that the formal statement is true, but mathematicians still need to confirm the statement matches the claim, and Lean's own guide treats un-reviewed AI-generated proofs as possibly misleading, recommending a sandboxed Comparator check with an independent second kernel.