Skip to content

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.

TheoremConditional resultOpen problem

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 N4 can be represented as N=p+q with primes p,q — 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 problemthe conjecture remains open

Nothing 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

Theorem

The following statements are checked by the Lean kernel in full: without sorry, without additional axioms, with local and reproducible checking.

JP1.lean — Theorem JP1

Theorem

Let N10 be an even number that admits an off-diagonal Goldbach pair — a pair of primes with p+q=N and pq. Then the indicator FN is not a coboundary on primes.

The formal definitions of the indicator FN 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

Theorem

Five 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 N from 10 to 1000: one decide-checked theorem per value of N. 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

Theorem

The 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

Refuted

The 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.

FileWhat the kernel checkssorryAxioms
JP1.leanTheorem JP1: the indicator FN is not a coboundary on primesnonenone
UnconditionalJP1.lean · ExtendedJP1*.leanper-instance decide certificates, jointly covering (with the base cases in JP1.lean) every even 10N1000nonenone
ExtendedJP1_500.lean, ExtendedJP1_1000.leanextended decide certificates (ranges up to 500 and up to 1000)nonenone
PMAPReductions.leanexact rational exponent identitiesnonenone (and no Mathlib)
PMAPCongruences.leancongruence equivalencesnonenone (and no Mathlib)
PPEChain.leancounterexample refuting the PPE chain (refuted line)nonenone

Proved modulo explicit classical inputs

Conditional result

CWC3Local.lean — a weighted second-moment chain

The file CWC3Local.lean assembles an analytic chain of three links:

  1. a weighted finite Parseval identity;
  2. orthogonality of Fourier modes;
  3. 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 A>0,

supα  nxμ(n)e(αn)  A x(logx)A

Here μ(n) is the Möbius function and e(x)=e2πix 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.lean chain 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

Theorem
493262532log54>710

The 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

Theorem

The 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 problem

Formal 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 EHμ 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 problem

A 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 problem

Full 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 problem

As 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 problem

Every axiom declaration in the formalization layer, by file:

FileAxiomsRole
AN1Silva.lean2external results (a source theorem and a computational verification) taken as inputs
BKPlus.lean1the 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.lean1a declared singular-series interface for the CWC3 statement
CWC3Local.lean3the explicitly listed classical inputs of the CWC3 chain (see the section above)
LVBottleneck.lean2two 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

Refutedline refuted

An 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 problem

The 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.lean line, 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).