Formalization in Lean 4
A part of the project is written in Lean 4 and checked by its kernel. Machine checking admits no ambiguity: every step either follows from the rules of the calculus or is explicitly marked as a gap. This page records what is fully machine-proved, what is proved modulo explicit classical inputs, and where the honest boundaries of the formalization lie.
Why formalization
A proof written by a human is checked by humans, and human refereeing errs: it skips steps, forgives transitions deemed obvious, loses signs. Machine checking eliminates this class of error on principle: the Lean kernel re-checks every step of a proof against the rules of the calculus and accepts no appeal to obviousness. The stakes here are high — the subject of the project is the binary Goldbach conjecture, the statement that every even can be represented as with primes — and reasoning that is merely almost checked cannot be trusted.
The project uses Lean 4 (pinned toolchain v4.30.0-rc2) and comprises 34 .lean modules (snapshot of 2026-07-19). The discipline operates at two levels. The Mathlib-free PMAP core contains no sorry, no axiom commands, and no imports of any kind; the CI script check_lean_core statically rejects any sorry/axiom/import occurrence in these files and additionally compiles them with core Lean. Across the full formalization layer, the complete honest account is: one sorry and 9 axiom declarations in 5 files — every one itemized under Honest boundaries below.
the conjecture remains openNothing on this page is a proof of the Goldbach conjecture, and nothing here brings it closer to the status of a theorem. The formalization does different work: it fixes the exact logical status of each step of the project — what is checked by the kernel unconditionally, what rests on classical results, and what remains open.
Fully machine-proved
TheoremThe following statements are checked by the Lean kernel in full: without sorry, without additional axioms, with local and reproducible checking.
JP1.lean — Theorem JP1
TheoremLet be an even number that admits an off-diagonal Goldbach pair — a pair of primes with and . Then the indicator is not a coboundary on primes.
The formal definitions of the indicator and of the notion of a coboundary are given in the file itself; the present page gives only the informal reading. The proof is complete — the file contains not a single sorry.
UnconditionalJP1.lean · ExtendedJP1_500.lean · ExtendedJP1_1000.lean
TheoremThese files turn Theorem JP1 into an explicitly checkable fact for an initial range: the decide tactic mechanically enumerates and certifies the statement for all even from 10 to 1000.
A decide certificate is not a numerical experiment but a fully fledged proof built by computation inside the logic: the kernel checks each case, and no assumptions are involved. Hence the word unconditional in the file name.
PMAPReductions.lean · PMAPCongruences.lean — the PMAP core
TheoremThe PMAP core contains exact rational exponent identities and congruence equivalences on which the subsequent constructions of the project rely.
The core is deliberately written without Mathlib: it is self-contained and does not pull in the external library. It contains no sorry and no axiom commands, and it sits under the CI ban of check_lean_core — a regression here cannot pass unnoticed.
PPEChain.lean — refutation of the PPE chain
RefutedThe PPE chain — the attempted route from Möbius cancellation to the conjecture — is refuted in Lean: the file constructs an explicit counterexample in which cancellation is present only over composite numbers and proves that this does not suffice to derive the conjecture. The refutation itself is a theorem: the counterexample is checked by the kernel in full.
| File | What the kernel checks | sorry | Axioms |
|---|---|---|---|
JP1.lean | Theorem JP1: the indicator is not a coboundary on primes | none | none |
UnconditionalJP1.lean | decide certificate for all even | none | none |
ExtendedJP1_500.lean, ExtendedJP1_1000.lean | extended decide certificates (ranges up to 500 and up to 1000) | none | none |
PMAPReductions.lean | exact rational exponent identities | none | none (and no Mathlib) |
PMAPCongruences.lean | congruence equivalences | none | none (and no Mathlib) |
PPEChain.lean | counterexample refuting the PPE chain (refuted line) | none | none |
Proved modulo explicit classical inputs
Conditional resultThe file CWC3Local.lean assembles an analytic chain of three links:
- a weighted finite Parseval identity;
- orthogonality of Fourier modes;
- a second-moment reduction.
Each link is derived in Lean, but the chain as a whole rests on explicitly listed classical axioms — mature results of analytic number theory that enter as assumptions. A typical input of this kind is the classical Davenport bound (1937) for Möbius sums: for every ,
Here is the Möbius function and is the standard notation for the additive character. All assumptions of this kind are collected in the file as an explicit list and are visible to an audit for axiom commands — they are not hidden deep in the dependency tree.
The
CWC3Local.leanchain is not an input to the Goldbach conjecture: it serves auxiliary statements of the project. It is placed in a separate section precisely because the status proved modulo classical results differs in principle from the status checked by the kernel unconditionally, and the two must not be conflated.
The arithmetic of external results
Results in the literature rest on concrete numerical constants and finite balances of estimates. An error in such arithmetic would be costly, so the project re-checks it with the Lean kernel rather than with a calculator.
RunboLi180.lean
TheoremThe inequality is proved in Lean as an exact statement. For orientation: the left-hand side is approximately 0.7506, which indeed exceeds 0.7.
LiLiu*.lean
TheoremThe family of files LiLiu*.lean checks finite constants and budgets of the sources — the accounting of how the contributions of individual estimates fit into the overall balance of the corresponding works.
These checks do not re-prove the works themselves in full: they certify only the finite numerical statements on which those works stand.
HuangLiBridge.lean · EHmuGoldbach.lean — the active bridge (July 2026)
Open problemFormal bookkeeping for the currently active line of work — a source-level replay of the Huang–Li conditional route. Lean proves the internal reductions: that the full hypothesis implies its fixed-class form; the transfer from the unweighted fixed-class estimate to its log-weighted form; a pure level-arithmetic combination of the stated inputs; and the finite endpoint and coprimality repairs used in the replay. The analytic hypotheses themselves enter only as explicit statement objects — definitions, with no sorry and no axiom in these two files — and remain open: no new estimate is proved here, and this work does not change the status of the conjecture.
Honest boundaries
Open problemA formalization is honest exactly to the extent that its gaps are listed explicitly. The following is a complete account of where the repository consciously falls short of full machine checking.
Scope of verified builds
Open problemFull lake build GoldbachFormalization passes against the pinned Mathlib revision are on record in the project’s pass ledger (most recently in the July 2026 passes). A successful build, however, is not a claim of completeness: Lean happily compiles modules that contain sorry scaffolds and axiom declarations, so a green build certifies only that what is proved type-checks. The complete inventory of the remaining gaps is itemized below, and the Mathlib-free PMAP core additionally passes the stricter check_lean_core audit.
The complete sorry account: one
Open problemAs of the 2026-07-19 snapshot the formalization contains exactly one sorry — in GoldbachPairTactic.lean (line 40): the correctness theorem for the search function findGoldbachPair, whose proof would require an induction over the function’s well-founded recursion. The lemma is off the critical path: no downstream result depends on it — the concrete Goldbach-pair instances used elsewhere are proved directly by decide, bypassing the function, and sample evaluations of the function itself are checked with native_decide. It is counted here as an open gap and nothing else.
The complete axiom account: 9 in 5 files
Open problemEvery axiom declaration in the formalization layer, by file:
| File | Axioms | Role |
|---|---|---|
AN1Silva.lean | 2 | external results (a source theorem and a computational verification) taken as inputs |
BKPlus.lean | 1 | the broad input hl_dominance_under_siegel — cited to classical sources, open as a formalization task; the genuinely unproved effective target is kept as a plain definition, not an axiom |
CWC3.lean | 1 | a declared singular-series interface for the CWC3 statement |
CWC3Local.lean | 3 | the explicitly listed classical inputs of the CWC3 chain (see the section above) |
LVBottleneck.lean | 2 | two implication steps of the large-values-bottleneck chain, taken as inputs; the bottleneck hypothesis itself is currently a placeholder, so the first axiom presently acts as a direct density-hypothesis input |
An axiom here is an honest marker: “this input is assumed, not proved”. Introducing axioms for open bridge statements is forbidden by the project’s guardrails; the declarations above record classical results, external sources, or explicitly open hard inputs.
SmallChen.lean — a retracted line, kept as a statement-only target
line refutedAn earlier version of this file carried a sorry for a sieve argument that, on audit, did not prove what it was meant to prove: the nearest audited theorem in the literature is substantially weaker than the claim the scaffold assumed. The unsupported sorry has been removed; the file now only defines the target as an explicitly unproved proposition — nothing is proved in SmallChen.lean itself, and the accompanying finite arithmetic repair is proved in PPEChain.lean. The line of argument it served has been refuted — see the parity barrier page. The file is kept deliberately, as a documented dead end: erasing the traces of failed approaches is poor research practice.
BLUEPRINT.md — a map of all gaps
Open problemThe root of the repository contains BLUEPRINT.md, a complete map of every sorry in the project together with an effort estimate for closing it. Anyone may compare the statements made on this page with the actual state of the code.
How the checking works
Local kernel checking
Trust is concentrated at a single point: the Lean kernel, a small and carefully audited codebase. Every proof is re-checked by the kernel locally, on the machine of the researcher or in CI. One need not trust the authors of the tactics, nor the authors of the project — it suffices to trust the kernel and to read the statements of the theorems.
No external API calls
Neither checking nor building contacts any external service. The outcome does not depend on the availability of third-party infrastructure and is reproduced on any machine with the pinned toolchain v4.30.0-rc2: the same files yield the same verdict of the kernel.
Static audits of imports, sorry, and axioms
In addition to the kernel itself, static audits are in place: scripts verify the import graph (what each file actually uses) and the absence of sorry and of foreign axioms in the core of the formalization. The CI script check_lean_core blocks any regression of this discipline.
See also
- Main results — what exactly is proved in the project, and under which status.
- The parity barrier — the counterexample to the
SmallChen.leanline, and other dead ends. - Methodology — how the research is organized as a whole.
- Publications — preprints and texts of the project.
External resources: lean-lang.org, the website of the Lean 4 language; mathlib4, the community library of formalized mathematics (which the PMAP core of the project deliberately does not use).