OpenAI’s 2026 math release is a body of research claims under scrutiny, not a blanket confirmation that every result is correct. A large release of AI-generated work raises hard questions about proof, authorship, and whether people can explain what the system produced.
A Lean formalization is a theorem and its proof encoded in Lean so the proof checker can validate the logical steps. That check can help, but it does not answer every question about a result’s place in mathematics. The useful distinction throughout this debate is between a claim being published and a claim being checked.
Key Takeaways
- OpenAI’s release contains research claims, not a guarantee that every result is correct.
- A Lean formalization lets a proof checker test encoded logical steps.
- Formal proof status does not decide whether a result is new or important.
- Experts must assess claims, their proofs, and their place in prior work.
- Repository counts can change between dated snapshots.
OpenAI 722 Math Claims Mathematician Scrutiny 2026: What Was Released?
OpenAI’s October 6 release placed 722 manuscripts in a public repository, grouped into 372 result families. Manuscripts are research write-ups, while a result family brings related results together.
The repository’s counts describe published work, not the number of problems the model attempted. The unnamed AI system was OpenAI’s internal model, and its work covered 17 mathematical fields. The repository also includes files that help readers inspect the claims and their proofs.
What the repository contains
The release includes mathematical results and supporting material, rather than only finished paper PDFs. Its files include:
- Manuscript PDFs and source files.
- Lean files for formalized results.
- Ten abridged reasoning summaries.
- Navigation files for browsing the repository.
The vast majority of results followed the same procedure. Work on a zero-free region for the Riemann zeta function and the Hodge conjecture for CM abelian varieties were exceptions.
How many problems led to the release
The evaluation posed about 4,000 problems, but an attempted problem and a published result are different units. A problem could lead to no published manuscript, while related manuscripts could form one result family.
The published results used an average of three hours of ChatGPT Pro thinking compute. That figure does not describe each attempt or establish how many attempts succeeded.
Readers comparing OpenAI’s reported math results with this release should keep those counting units separate.
An evaluation attempt and a published result are different units, so their counts should not be treated as a success rate.
The OpenAI math repository presents the files as a collection of related research materials. The average compute figure describes the published results, not the time or resources needed for every individual attempt.
Why Does the GitHub Count Change Over Time?
The October 30 README lists 721 manuscripts in 373 families, a different snapshot from the October 6 release. Those dates matter because a repository can show a later version than the original announcement.
The October 6 announcement counted 722 manuscripts and 372 result families. The October 30 README counted 721 manuscripts and 373 families. These are separate measures: one counts manuscripts, while the other groups related results.
A manuscript total can change when files are revised, and a family total can change as related results are grouped. The dated counts show a difference, but the figures alone do not explain why it happened.
That distinction matters when readers compare the release announcement with the repository’s current index. The word “results” may refer to individual claims, manuscripts, or a grouped family, depending on the count being discussed.
OpenAI’s repository README and history give readers a dated view of the collection. A number without its snapshot date can make two accurate counts appear to conflict.
Check the date of a repository snapshot before comparing its counts with the original release.
Which Mathematical Claims Are in the Catalogue?
The catalogue includes claims ranging from a formalized zero-free region for Dirichlet L-functions to results without listed Lean formalizations. Its entries differ in scope and in the support provided.
A catalogue label does not by itself settle novelty or correctness. Readers need the exact claim, its proof, and its relation to earlier mathematics.
What the zeta-function entry claims
The Riemann zeta function is one example of a Dirichlet L-function. The catalogue lists a Lean formalization for the claim that every Dirichlet L-function is zero-free in the region Re(s) > 7/8.
This is a result about a zero-free region, not a proof of the Riemann hypothesis. The full hypothesis concerns zeros in a different and much broader way.
Formalized examples and listed gaps
The catalogue marks some claims as formalized and others without a listed formalization. The distinctions include a conjecture’s scope and whether the catalogue lists formal proof files.
| Claim | Catalogue status | Scope or distinction |
|---|---|---|
| Dirichlet L-function zero-free region | Lean formalization listed | Re(s) > 7/8, including the zeta function |
| Mahler conjecture | Symmetric case formalized | Nonsymmetric case not listed as formalized |
| Kaplansky zero-divisor conjecture | Counterexample formalized | Listed as a counterexample |
| Kaplansky direct-finiteness conjecture | Two cases formalized | Characteristic two and odd characteristic |
| Three other claims | No Lean formalization listed | Free group factors; pi’s exponent; Hilbert’s tenth problem over rationals |
The three claims without listed Lean formalizations concern whether all nonabelian free group factors are isomorphic, whether pi’s irrationality exponent is exactly 2, and a negative answer to Hilbert’s tenth problem over the rationals.
Read the precise mathematical statement before turning a striking problem name into a claim of a complete solution.
What Does a Lean Formalization Actually Verify?
Lean can check the encoded proof’s logical steps, but it cannot certify that a result is important or well understood. Its check is specific to the formal statement and proof supplied.
A valid formal proof does not settle every scholarly question about a manuscript. The theorem statement must also match the written claim, and human review must assess the result’s place in mathematics.
What the proof checker can establish
Lean checks each encoded step against its trusted core and the theorem being proved. If the proof passes, the system has validated that formal argument under those rules.
That is useful evidence about the mathematics represented in the Lean file. It does not automatically show that the manuscript’s wording says the same thing.
What formalization cannot decide
The repository reports that about 42% of its top-line results have Lean formalizations. The October 6 catalogue also lists formalizations of the main result for 162 papers.
Those figures measure different things: one counts top-line results, while the other counts papers with a formalized main result. Neither measure says whether people understand the argument or whether the result is new.
| Question | What Lean can check | What it cannot establish |
|---|---|---|
| Logical steps | Whether encoded steps prove the formal theorem | Whether the theorem is important |
| Match to manuscript | The formal statement itself | Whether it matches the written claim |
| Novelty | No novelty judgment | Whether earlier work already proves it |
| Significance or exposition | No human judgment of value or clarity | Whether the result matters or is well explained |
OpenAI warns that unformalized results could have issues. A formalization also needs human review to compare its statement with the manuscript.
Readers assessing claims about AI output can also consider why clues about AI writing are not proof of authorship or accuracy.
A formal proof is strongest evidence when its theorem statement is checked against the claim the manuscript actually makes.
What Changed After OpenAI Found a Sign Error?
A sign error found in OpenAI’s audit led to three withdrawals and revisions to 14 other manuscripts. The error had a wider effect because two manuscripts depended on a shared construction.
OpenAI found the errors during its own audit, not through a reported outside discovery. The problem affected an argument in one manuscript and the construction used by two others.
The three connected withdrawals
On October 7, 2026, OpenAI withdrew three manuscripts after finding the sign error. The first paper’s argument was undermined, and two dependent papers relied on its construction.
| Manuscript | Connection to the error | Disposition |
|---|---|---|
| “Algebraicity of Weil classes on split abelian eightfolds” | Sign error undermined an argument | Withdrawn |
| “Algebraicity of Kuga-Satake Correspondences for K3 Surfaces” | Used the dependent construction | Withdrawn |
| “The rational Hodge conjecture for products of K3 surfaces” | Used the dependent construction | Withdrawn |
The other revisions
OpenAI revised 14 other manuscripts. The changes included proof repairs, corrected statements, clearer hypotheses and dependencies, and a citation correction.
These changes show why a manuscript’s status can change after publication. A correction may affect a proof, a claim’s wording, or the way readers trace a result to earlier work.
A correction notice should be read alongside the version of the manuscript it changes.
Why Did the Release Draw Objections?
The central objection is that publishing a large batch of claims can shift the burden of verification onto mathematicians without ensuring meaningful scholarly engagement. The dispute concerns process, not a finding that every manuscript is wrong.
The Association for Human Mathematics called for mathematicians to discontinue work with OpenAI on this kind of release. Its statement described releasing more than 700 files at once as a demonstration of power rather than scholarship.
The objection to release at scale
The Association for Human Mathematics objected to releasing a large batch without the ordinary scholarly process. It argued that a demonstration of power does not replace the work needed to check claims and build shared understanding.
That position represents an organized group, not every mathematician. The debate over OpenAI’s 722 math claims and mathematician scrutiny in 2026 focuses on process, verification, and human understanding.
The concern about human understanding
Terence Tao raised a related concern about contributors who may be unable to explain or defend AI output. A contributor who cannot do that may not take part meaningfully in mathematical research.
The concerns include:
- Who takes responsibility for each mathematical claim.
- How much time and labor researchers need to verify the work.
- Whether contributors can explain the argument and defend it.
Those questions matter even when a claim turns out to be correct. Scholarly work includes more than producing a statement; it also requires people who can account for its reasoning.
Treat the group’s statement as an organized position, not as proof of a field-wide consensus.
What Did the Advisory Group Recommend?
The advisory group’s September 29 guidance asked labs to stop testing advanced mathematical problems on proprietary models. That advice addressed testing, not how a lab should publish its results.
Guidance about model testing and guidance about research release are separate issues. OpenAI said it consulted the group on guidance for the release.
Guidance on testing advanced problems
The Advisory Group on Mathematics and Artificial Intelligence asked labs to stop testing advanced mathematical problems on proprietary models. A proprietary model is controlled by its maker rather than open for general use.
The request raised a tension because OpenAI said it had consulted the group on release guidance. That consultation concerned publication advice, while the group’s recommendation on proprietary models concerned how labs test advanced problems.
Disclosure and reproducibility
Outsiders cannot reproduce a generation process fully without access to the model, prompts, and detailed compute information. They can still inspect the resulting manuscripts and Lean files, but that checks different parts of the work.
Checking a proof file asks whether encoded steps support a formal statement. Reproducing the process asks how the model reached that result and whether the same inputs produce similar work.
The group also described the October 6 release as the start, not the end, of human understanding. Reproducibility requires enough information to examine how a result was produced, not only a file containing the result.
What Do Mathematicians Need to Check Before Trusting a Result?
Mathematicians cannot assess a collection of this scale with a single yes-or-no verdict; they have to inspect claims in their own areas. Expert review is local because different fields use different tools and prior results.
Each claim needs checks for correctness, fit between statement and proof, prior work, and clear exposition. A headline count cannot replace those steps.
Cornell mathematician Alex Townsend recommended separating Lean-verified manuscripts from other claims. That approach can help reviewers sort work by one form of evidence without treating formalization as a full verdict.
Kevin Buzzard said only around six algebraic number theory results immediately stood out to him. Brendan Hassett said a write-up in his area made little sense after a quick read.
Those reactions speak to triage and exposition, not a finding that the full collection is wrong. A difficult write-up may need clearer explanations before other specialists can judge its proof.
A separate audit of ten earlier OpenAI results discusses how human reviewers can distinguish confirmed errors, gaps, and exposition issues. Its scope is that earlier announcement, not the 722-manuscript release.
Researchers comparing the argument with a human audit of earlier AI-generated proofs should keep that difference in scope clear.
A result that is difficult to read needs clearer exposition before other researchers can build on it.
How Can Readers Audit a Manuscript in the Repository?
Start with one claim and compare its manuscript statement with the matching Lean statement, if a formalization exists. One claim at a time makes a large repository easier to assess.
Readers can inspect files and version notes, but their presence does not mean a manuscript received peer review. The comparison tests what the manuscript says against what the Lean file proves.
Which files to compare
Find the result family in the repository index, then open its manuscript. Compare the theorem in the text with the matching formal statement, when a Lean file exists.
Then check whether the citations support the manuscript’s claim of novelty. Prior work may affect whether a result is new, even when its proof is sound.
- Find the result family in the repository index.
- Open the manuscript for the claim.
- Compare the formal statement with the written claim.
- Review citations and version notes.
How version history helps
OpenAI describes the manuscripts as raw research data rather than polished academic papers. It defers to the mathematics community on credit, precedence, and concurrent work.
OpenAI said it would preserve release history, add corrections and revisions as new versions, and keep earlier versions accessible. Earlier files matter because a later correction may change what a cited result supports.
For a broader look at checking AI capability claims against evidence, readers can see how AI claims can exceed their supporting evidence. Record the manuscript version alongside any claim you cite so later corrections remain traceable.
What Will OpenAI Do to Support Follow-Up?
OpenAI has described three kinds of follow-up support: a possible model release, community hosting, and funded assessment programs. These are plans, not completed steps.
Each commitment could support review, but none verifies a mathematical claim by itself. The work still depends on specialists examining the results.
OpenAI described these planned or pledged actions:
- Work toward responsibly releasing the internal model.
- Explore community-hosted alternatives for the papers.
- Fund workshops, conferences, and special programs to help assess results.
A model release could let outside researchers study the system more directly. Community hosting could support access to the papers, while funded programs could give researchers time to assess claims.
Those efforts would address access and capacity, not settle whether a specific proof works. A workshop can bring people together, but its value depends on the mathematical checks that follow.
A funding pledge creates capacity for review, but the mathematical conclusions still depend on the review itself.
Why Does This Debate Matter Beyond One Release?
The broader issue is whether faster production of claims can be matched by the human capacity to assess and use them. Mathematical progress requires more than generating statements.
A result must be checked, understood, and placed in its scholarly context before others can build on it. That work asks researchers to test proofs, compare claims with prior work, and explain what a result means.
The Advisory Group on Mathematics and Artificial Intelligence described the October 6, 2026, release as the beginning, not completion, of human understanding. It said the mathematical community needed to assess the work.
This point reaches beyond one company or one set of files. Science advances when researchers can question a claim, explain its reasoning, and use it in later work.
AI systems may produce mathematical statements at a pace that tests review capacity. The gap between output and assessment matters if researchers cannot check claims as quickly as they appear.
Publication begins the work of understanding; it does not finish it.
The group’s point is that publication begins the work of understanding rather than completing it.
Conclusion
The most defensible conclusion is to assess each result on its own evidence rather than judge the collection by its size. Neither the manuscript count nor the withdrawals alone settles the collection’s value.
A claim deserves attention to its formal status, correctness, novelty, and place in the field. Those measures help separate a checked proof from a claim that still needs review.
Before relying on a result, wait for relevant specialists to establish what it proves and how it fits into the field.
FAQ
Does OpenAI’s release prove the Riemann hypothesis?
No, the listed result is a separate claim about a zero-free region. It states that Dirichlet L-functions, including the Riemann zeta function, have no zeros when Re(s) > 7/8. The Riemann hypothesis concerns the location of all nontrivial zeros, so that region does not prove the full hypothesis. The problem name alone does not show what the manuscript establishes.
Does the 42% Lean figure mean 42% of the manuscripts are formally verified?
No, the 42% figure refers to top-line results with Lean formalizations. The October 6 catalogue separately listed 162 papers whose main result had a formalization. A top-line result and a paper are different counting units, so the two figures answer different questions. Neither number shows whether a formal statement matches every claim in its manuscript.
Can an outside researcher reproduce the internal model’s results?
No, an outside researcher cannot reproduce generation with the internal model while that model remains unreleased. Researchers can inspect the published manuscripts and available Lean formalizations, but those files do not provide the model itself, its prompts, or detailed compute information. That means checking a proof and reproducing how the system generated it remain separate tasks.
Do the three withdrawals show that the other manuscripts are wrong?
No, the withdrawals establish a specific error cascade in three connected manuscripts. A sign error undermined one argument and a shared construction used in two dependent papers. That finding does not decide the status of the remaining claims. Each other manuscript needs its own review, and a correction to one result does not prove that unrelated results are wrong.
How can a mathematician flag a problem in a manuscript?
A mathematician can compare the written claim with its formal statement and version notes, then report a discrepancy through the repository’s correction process. The report should identify the manuscript version and the exact statement or proof step at issue. That detail helps others trace the concern and see whether a later version repairs it or changes the claim.
Why did the October 30 repository count differ from the October 6 release?
The October 30 README listed 721 manuscripts in 373 families, while the October 6 release listed 722 manuscripts in 372 families. A manuscript count and a family count measure different things. Repository files can also change across dated snapshots. Compare counts only when the snapshot dates and counting units are clear, rather than treating either figure as timeless.
