Why formalize the Four Color Theorem in Lean 4?
The Four Color Theorem links a short mathematical statement to a large collection
of finite checks. For contributors to graph theory and proof assistants, it is a
concrete test of whether abstract mathematics, executable verification, and a
public theorem statement can share one auditable foundation. The proposed result
is a complete Lean 4 formalization, reusing Mathlib and adapting the established
proof architecture to Lean.
The mathematical result is established. Robertson, Sanders, Seymour, and Thomas
gave a modern computer-assisted proof in 1997. Gonthier subsequently developed a
Coq formalization covering both mathematical reasoning and computation, described
in his 2005 report and 2008 Notices article. This mission is classified as
ResearchPaper because it formalizes these published results.
(RSST,
Gonthier 2005,
Gonthier 2008)
Graphs, drawings, and colors
The root Lean interface uses Mathlib's SimpleGraph: a finite vertex set
with a symmetric, irreflexive adjacency relation. Edges in this representation
carry no additional identities or multiplicities. The conventional statement
also permits parallel edges. Already-proved local infrastructure uses Mathlib's
Graph V E to erase parallel edges while preserving a genuine plane drawing and
proper vertex colorings; only the actual vertex set must be finite. A proper vertex coloring assigns a color to every vertex and
assigns different colors to adjacent vertices. Four available colors means at
most four colors are used; there is no requirement that each color occur.
A planar drawing places distinct vertices at distinct points of the real
plane and represents each edge by an injective continuous arc joining its
endpoints. An arc contains no other vertex, and arcs of different undirected
edges meet only at shared endpoints. Reversing the orientation of an edge
reverses its parameterization. A graph is planar when such a drawing exists.
This is a geometric condition independent of coloring and of the eventual
configuration checkers. Gonthier discusses the graph-embedding formulation in
Section 2, PDF p. 4 of the
2005 report.
Write V for the vertex set, G for its adjacency relation, and
C={0,1,2,3} for the available colors. Empty graphs, isolated vertices, and
disconnected graphs are included. The drawing is a witness to a hypothesis;
the theorem does not impose coordinates, a prescribed embedding, or a
straight-line representation.
Formalization target
For every finite loopless planar graph, establish
∀G=(V,E),Planar(G)⟹∃c:V→C,∀v,w∈V, {v,w}∈E⟹c(v)=c(w).
The draft Lean target is FourColor.four_color: for every finite vertex type
and every SimpleGraph on that type, FourColor.IsPlanar G implies
G.Colorable 4. Its graph formulation follows RSST's Section 1, PDF p. 2 of the
author-hosted manuscript.
The manuscript's PDF page numbers differ from the journal's pagination.
The exact unchanged root signature is:
FourColor.four_color.{u} :
∀ (V : Type u) [Finite V] (G : SimpleGraph V),
FourColor.IsPlanar G → G.Colorable 4
This is an open target signature, not a completed proof. The existing
FourColor.FinalAudit.multigraph_four_color_of_necessary_targets conditionally
connects the mission obligations to the conventional finite loopless planar
multigraph statement. Its drawing has distinct vertex positions and injective
continuous arcs for each edge identity; erasing parallel edges is proved to
preserve planarity and every proper-coloring constraint. This bridge adds no
simplicity, connectedness, triangulation, or nonemptiness assumption to the
conventional conclusion. The root target itself remains unchanged.
An equivalent combinatorial formulation is welcome only with the formally
verified translations needed to recover this target. If equivalence is claimed,
both directions must be proved under precisely stated conventions. In
particular, a hypermap coloring theorem alone does not complete this mission.
The original seven structural milestones remain unchanged:
| Milestone | Deliverable |
|---|
| 1. Graph realization | Construct a planar plain hypermap whose faces represent exactly the nonisolated graph vertices and whose edge steps encode precisely adjacency. |
| 2. Cubic normalization | Construct a plain cubic hypermap with six times as many darts, preserving planarity and bridgelessness and transporting a coloring back. |
| 3. Minimal counterexample | Choose a least-dart counterexample within the planar, bridgeless, plain, precubic comparison class. |
| 4. Counterexample structure | Prove cubicity, connectedness and minimum face arity five as consequences of minimality. |
| 5. Charge conservation | Prove total face charge 120c for c components under arbitrary rational dart transfers, and a positive-charge face when connected. |
| 6. Elimination | Complete the source's reducibility and unavoidability analysis to exclude every minimal counterexample. |
| 7. Hypermap theorem | Assemble four-colorability for all planar bridgeless hypermaps. |
These correspond to Gonthier's reductions in Section 3, PDF pp. 6–9, and
development in Sections 5.1–5.6 of the
2005 report.
Exact locations and executable-reference declarations accompany each milestone.
Milestones 2, 3 and 6 imply milestone 7; milestones 1 and 7 imply the graph
target. Those two conditional implications have been checked in Lean against
the exact proposed statements. Milestone 6 now has thirteen concrete supporting targets:
| Core target | Deliverable |
|---|
| Catalogue geometry | Prove geometric admissibility of every one of the fixed 633 configurations. |
| Catalogue reducibility | Kernel-check reducibility of every fixed map and contract using the proved complete checker or a verified refinement. |
| Reflection | Prove that the explicit mirror preserves minimal counterexamples. |
| Geometric exclusion | Prove that a C-reducible configuration cannot occur in a minimal counterexample; this includes the Birkhoff and patching arguments. |
| Presentation soundness | Prove the concrete finite presentation checker's generic soundness as one route to coverage. |
| Seven coverage cases | Independently handle positive hubs of degrees 5, 6, 7, 8, 9, 10 and 11, allowing reflected occurrences and unbounded neighboring arities. |
| Transfer bound | Bound each directed transfer by five under the explicit absence-of-configurations hypothesis; proved arithmetic then excludes positive hubs of degree at least 12. |
The fixed catalogue and fixed rules are shared by both branches. The local Lean
assembly checks that reducibility, geometric exclusion, reflection, the transfer
bound, the seven degree cases, and milestones 4–5 imply milestone 6. It then
connects to the unchanged hypermap and graph targets. The generic presentation
checker offers a sufficient route to the semantic degree targets; its ability to
certify every source presentation is not presumed. That route also requires
actual presentation certificates and proofs of acceptance for the degree cases.
Generic soundness and catalogue geometry alone do not supply those witnesses.
Direct proofs of the seven semantic coverage obligations remain valid. Catalogue
geometry remains a separate, meaningful finite theorem.
Exact mission obligations
There are 21 open theorem targets: 20 supporting milestones and one root.
Every name below has prefix FourColor.. All remain future mission work; the
checked conditional assembly is not a proof of any of these targets.
| # | Exact target name | Obligation |
|---|
| 1 | graph_realization | Realize a finite drawn graph by a planar plain hypermap with exact face/adjacency incidence. |
| 2 | cubic_normalization | Construct the sixfold plain cubic map with the stated preservation and coloring transport. |
| 3 | minimal_counterexample_exists | Select a least-dart counterexample in the precubic comparison class. |
| 4 | minimal_counterexample_structure | Derive cubicity, connectedness and face arity at least five from minimality. |
| 5 | charge_conservation | Prove total charge and existence of a positive face for a connected host. |
| 6 | catalogue_embeddable | Prove the fixed 633 entries satisfy configuration geometry. |
| 7 | catalogue_reducibility_certificates | Establish accepted reducibility certificates for every fixed entry. |
| 8 | mirror_minimal_counterexample | Preserve minimal-counterexample status under the specified mirror. |
| 9 | reducible_configuration_exclusion | Exclude a C-reducible occurrence from a minimal counterexample. |
| 10 | discharge_presentation_soundness | Prove generic soundness of the concrete finite presentation checker. |
| 11 | degree_5_coverage | Derive a catalogue occurrence, in either orientation, from a positive degree-5 hub. |
| 12 | degree_6_coverage | Establish the same semantic occurrence obligation for degree 6. |
| 13 | degree_7_coverage | Establish the same semantic occurrence obligation for degree 7. |
| 14 | degree_8_coverage | Establish the same semantic occurrence obligation for degree 8. |
| 15 | degree_9_coverage | Establish the same semantic occurrence obligation for degree 9. |
| 16 | degree_10_coverage | Establish the same semantic occurrence obligation for degree 10. |
| 17 | degree_11_coverage | Establish the same semantic occurrence obligation for degree 11. |
| 18 | discharge_transfer_bound | Bound each transfer by five under minimality and absence of catalogue occurrences in either orientation. |
| 19 | no_minimal_counterexample | Assemble the core argument to exclude all minimal counterexamples. |
| 20 | hypermap_four_color | Assemble four-colorability of every planar bridgeless hypermap. |
| 21 | four_color | Prove the unchanged finite planar graph root above. |
The degree cases quantify over minimal counterexamples with the exact positive
score defined by the fixed rules; neighboring degrees have no artificial upper
bound. The dependency path uses 16 necessary input targets to derive targets 19,
20 and 21. Targets 6 and 10 support the optional presentation-certificate route.
None of targets 19, 20 or 21 is assumed as a shortcut in this assembly.
What completion would provide
The theorem provides a uniform existence guarantee for all finite planar graphs,
without a bound on their size. Its Lean development should also make reusable
graph embeddings, finite combinatorial maps, coloring transports, and verified
finite checkers available to later work.
The existing
Rocq development
is an executable reference for definitions, dependency structure, and proof
behavior. It is not a proof import into Lean. The proposed contribution is a Lean
development whose proof objects and computation are justified within Lean's
documented foundations. A mechanically translated collection of scripts is not
required; contributors should choose abstractions that work well with Mathlib.
Where the difficulty lies
Checking finitely many small graphs does not establish the theorem for arbitrary
finite graphs. The development must justify why its finite computational tasks
suffice, and must connect their results to the graph statement. The mathematical
and computational obligations must meet at explicit, proved interfaces.
There is also a representation gap. The standard target concerns vertex
colorings of graphs drawn in the plane, whereas the reference implementation's
combinatorial core colors faces of planar bridgeless hypermaps. The latter
endpoint is four_color_hypermap in
combinatorial4ct.v.
Correct treatment of duality, connected components, and isolated vertices is
part of the work. Renaming a combinatorial predicate “planar” cannot establish
that connection.
Formalization scope and acceptance criteria
Use Lean 4 with a supported, pinned Mathlib revision. The initial draft is checked
against Lean v4.30.0 and Mathlib
c5ea00351c28e24afc9f0f84379aa41082b1188f. Any later migration must preserve
the statements and repeat the relevant checks. Reuse Mathlib's graph and coloring
interfaces where appropriate, and develop missing infrastructure as reusable
modules. The topological definition must not assume colorability, successful
certificate verification, or the conclusion of an intermediate theorem.
The definition layer now provides plane drawings, finite permutation hypermaps,
an exact graph/face incidence representation, minimal counterexamples, and
rational face charges. Coloring equivalence across a face representation is
proved for every positive number of colors, with isolated vertices handled
explicitly. Exact Euler equality defines combinatorial planarity; geometric
realization is a theorem obligation and cannot be assumed from the name.
The concrete core now defines configurations, ordered boundary traces,
contracts, chromograms, Kempe closure, kernel preembeddings and reflected
occurrences. The reference reducibility checker has proved soundness and
completeness. All 633 maps, rings and contracts are literal data with
kernel-validated table/index proofs. The 38 base entries and their 71 symmetrized
entries are explicit, and the executable matcher has proved semantic
correctness. These infrastructure results do not prove the catalogue's geometric
validity, its reducibility, or unavoidability.
The production targets import FourColor.CompactCatalogue.configurations, a
compact catalogue containing the same literal
maps, rings and contracts. A generic verified decoder constructs validated
entries without storing large evaluated proof terms in every import. A separate
kernel-checked comparison proves exact ordered equality with the original
catalogue, proves that every raw entry is accepted, and proves that none is
dropped. The original certificate batches remain available for that audit but
are excluded from production target imports. This representation change does
not alter any of the 21 mathematical obligations.
Data provenance is pinned to Rocq commit
c1d6b1cd5288bea4b067aac13cdde3c18dffe018. Independent fresh-source comparisons
check all 633 configurations and every base/expanded rule entry against that
snapshot, including actual evaluated Lean payloads. These comparisons establish
source correspondence; they are not proofs of reducibility or unavoidability.
The duplicate-data gate rejects unexplained or unintended duplicates and
permits verified source-mandated repetition encoding multiplicity or weight.
The only repeated rule payload is drule1, deliberately listed twice: the source
explains its two-point transfer in
discharge.v, lines 17–24
and retains both copies in base_drules (line 145). The Lean rule-match count
also counts both copies, preserving weight two. Thus there are 38 base entries
with 37 distinct payloads, and 71 expanded entries with 70 distinct payloads.
Both copies must remain. No configuration duplicates or other repeated rule
payloads are permitted without separately verified source justification.
The reference reducibility evaluator is exponentially expensive. Contributors
should implement verified compressed representations or efficient checkers,
with acceptance implying the same semantic C-reducibility. Completeness of the
reference checker then recovers the stated certificate-existence target.
The presentation language is a transparent finite baseline; its generic
soundness is an open target, and no completeness claim is made. Source-style
quizzes/hubcaps or direct Lean proofs can close the same seven semantic coverage
targets. This keeps performance choices separate from the mathematical endpoint.
All computational claims needed by the theorem must be established in Lean.
External generators may prepare candidate data or certificates, but their output
must be validated by a checker with proved correctness, and the resulting proof
must be accepted by the Lean kernel. A recorded successful run of an external
program is insufficient. The final theorem and its dependency closure must
contain no sorry, admit, unproved custom axiom, or unsupported computational
assumption. An axiom audit must identify only Lean/Mathlib's documented foundations.
The current 37-declaration conditional/infrastructure audit uses only propext,
Classical.choice and Quot.sound; it does not claim an unconditional Four Color
proof. Python generators and runtime JSON extraction are outside the mathematical
trust boundary and cannot discharge the 21 targets.
Completion requires a reproducible repository in which lake build succeeds
from a clean environment and builds the final theorem. Pin toolchain,
dependencies, source revisions, and certificate data; document regeneration and
verification commands. Maintain a dependency map connecting Lean declarations
to exact paper locations and Rocq declarations, and record justified differences
in representation. The local multigraph adapter already justifies forgetting
parallel-edge multiplicities and transports proper colorings. Any auxiliary restrictions such
as connectedness or nonemptiness must be discharged before the root theorem.
The current statement and conditional builds verify proposal infrastructure.
Success requires proofs of the mission obligations and the final theorem in
the reproducible clean build, with no unproved assumptions beyond the documented
Lean/Mathlib foundations. All 21 targets remain open at proposal finalization.
The submission snapshot records the repository base commit, exact working-file
hashes, toolchain, Mathlib revision, payload hashes and audit report; it must not
misrepresent uncommitted files as contents of the base commit.
Selected references
- Georges Gonthier, A Computer-Checked Proof of the Four Colour Theorem,
technical report, 2005. Sections 2–5.
Microsoft Research PDF.
- Georges Gonthier, Formal Proof—The Four-Color Theorem, Notices of the AMS
55(11), 1382–1393, 2008. Theorem 1 and the formalization architecture.
AMS PDF.
- Gonthier and Rocq-community contributors, fourcolor, executable formalization,
pinned to commit
c1d6b1cd5288bea4b067aac13cdde3c18dffe018.
Repository.
- Neil Robertson, Daniel Sanders, Paul Seymour, Robin Thomas, The Four-Colour
Theorem, Journal of Combinatorial Theory, Series B 70(1), 2–44, 1997.
DOI;
author-hosted manuscript.