Formalization in Lean 4
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 boundaries of the formalization lie.
Why formalization
A proof written by a human is checked by humans, and human refereeing errs: it skips steps, waves through transitions deemed obvious, loses signs. Machine checking eliminates this class of error in 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 41 .lean modules (snapshot of 2026-07-23). 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, or native_decide occurrence in these files and additionally compiles them with core Lean; its 28 rational identities are proved by kernel evaluation (decide +kernel). Across the full formalization layer, the complete honest account is: no sorry and 9 axiom declarations in 5 files — every one itemized under Honest boundaries below.
Update, July 2026. Two substantial lanes have been added to the layer beyond the older modules described below. The first machine-checks the closing argument of the Huang–Li conditional bridge, which is where the program’s main line runs; the second is a partial, self-contained treatment of Siegel’s theorem. The bridge is not unconditional and Siegel’s theorem is not proved. In both lanes every statement that is not proved is carried as an explicit Prop — never as an axiom — so that the list of open inputs can be read off the file rather than reconstructed from prose. Both are described in full below.
Open problem — 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 of Theorem JP1 is complete — the file contains not a single sorry.
UnconditionalJP1.lean · ExtendedJP1*.lean — instance certificates
TheoremFive instance files (UnconditionalJP1, ExtendedJP1, ExtendedJP1_500, ExtendedJP1_1000, ExtendedJP1Fill), together with the base cases in JP1.lean, certify a per-instance statement for every even from 10 to 1000: one decide-checked theorem per value of . These are individual certificates, not a single quantified theorem over the range.
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. It is a deliberately standalone module — a kernel-checked record of the exponent bookkeeping, not an import that other constructions of the project build on.
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 · ExtendedJP1*.lean | per-instance decide certificates, jointly covering (with the base cases in JP1.lean) every 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 resultCWC3Local.lean — a weighted second-moment chain
The 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: an audit that greps for axiom finds all of them, and none is buried 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 layer contains no sorry, but that is the least interesting of its guarantees: the real gaps are the statements deliberately left unproved, and they come in three kinds — named Props that no theorem discharges, explicit axiom declarations, and modules retained as documented dead ends. All three are listed here; the blueprint file maps the remainder.
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: none
Open problemAs of the 2026-07-23 snapshot the layer contains no sorry at all. The last one — the correctness theorem for the search function findGoldbachPair, which had stood since April 2026 — was closed in July by an induction over the function’s well-founded recursion, using the principle Lean generates automatically for such definitions. The statement was not weakened to make it provable: it is unchanged, and only the proof body and its docstring were rewritten.
Two qualifications keep this from being read as more than it is. First, sorry-free is not axiom-free: the 9 axiom declarations listed below are untouched by this, and they are the substantive gaps. Second, the 3 native_decide occurrences in the layer — all in this one file — extend the trusted base from the kernel to the Lean compiler (visible as Lean.ofReduceBool under #print axioms), and are used only for non-load-bearing sample evaluations, never for a result claimed as kernel-checked.
The audit script that produces these numbers now carries an empty allowlist, so any sorry introduced in future is reported as unexpected and fails the check rather than being silently tolerated.
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
Refuted — 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 formalization package contains BLUEPRINT.md, a map of the open formalization debts together with effort estimates for closing them. 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.
Reproducible offline
Kernel checking itself contacts no external service: once the pinned dependencies (Mathlib and its packages, fetched over the network during the initial setup) are in place, the outcome is reproduced offline 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).