---
title: 'Atlas: Autoformalized Textbook Library at Scale'
url: https://www.emergentmind.com/topics/autoformalized-textbook-library-at-scale-atlas
type: topic
---

# Atlas: Autoformalized Textbook Library at Scale

Searching arXiv for the cited Atlas-related papers to ground the article in current literature.
Autoformalized Textbook Library At Scale (Atlas) denotes a line of research centered on converting textbook mathematics into machine-checked formal libraries at project scale. In recent work, the term is used both for concrete verified corpora and for the methodological stack needed to produce them: large-scale natural-language-to-formal-language data generation, verifier-in-the-loop compilation and proof repair, multi-agent repository orchestration, and human-guided semantic review [2605.29955][2602.17016][2502.05567][2604.16347]. The resulting program moves autoformalization from isolated theorems and short snippets toward end-to-end textbook ingestion, with explicit concern for dependency management, buildability, proof completion, provenance, and semantic fidelity.

## 1. Atlas as artifact, framework, and review layer

The literature does not present Atlas as a single monolithic system. Rather, separate papers instantiate different layers of the same objective. "ATLAS" in "Autoformalizing Theorems through Lifting, Augmentation, and Synthesis of Data" is a data-generation framework for constructing large NL–FL corpora in Lean4. "Atlas" in "Formalizing Mathematics at Scale" is the resulting collection of verified Lean 4 libraries produced by AutoformBot. In "M2F: Automated Formalization of Mathematical Literature at Scale," Atlas is described as something that can be concretely instantiated by adopting M2F’s project-scale, verifier-in-the-loop methodology. "Lean Atlas" is an integrated proof environment for semantic verification of large formalization projects [2502.05567][2605.29955][2602.17016][2604.16347].

| Work | Primary role | Reported artifact |
|---|---|---|
| ATLAS | Data generation for NL–FL theorem statements | 10-iteration Lean4 pipeline with concept lifting, synthesis, and augmentation |
| M2F | End-to-end project-scale autoformalization in Lean | 241 files, 4,116 declarations, 153,853 lines from 479 pages |
| AutoformBot / Atlas | Multi-agent production of textbook libraries | 26 textbooks, 45,000+ declarations, 483,918 lines |
| Lean Atlas | Human-in-the-loop semantic review environment | Dependency-graph extraction, Lean Compass, interactive web viewer |

This suggests that Atlas is best understood as a layered program of work rather than a single algorithm. The shared target is a large, reusable, formally verified library derived from textbook mathematics, but the enabling techniques differ substantially: some papers optimize training data, some optimize project compilation and proof repair, some optimize software-engineering throughput, and some optimize semantic auditing.

## 2. Why textbook-scale autoformalization is difficult

Textbook-scale autoformalization is harder than theorem-level translation because project-level constraints dominate. M2F characterizes the main failure sources as cross-file import choices, name resolution, namespace governance, typing cascades, and implicit dependencies, often before proof search is even meaningful. At this scale, a library must compile end-to-end; otherwise the prover cannot even load goals [2602.17016].

ATLAS frames the problem from a data perspective. Formal languages such as Lean, Isabelle, Coq, and HOL Light are unforgiving: a single missing type annotation or mis-specified quantifier breaks compilation, and even syntactically valid output can miss the intended semantics. Natural-language mathematics is also highly contextual. If a statement invokes a concept not present in the formal library, the missing definition must be formalized first, which the paper describes as nontrivial even for experts. This makes large, high-quality NL–FL corpora a central bottleneck [2502.05567].

A second difficulty is that mechanical correctness is not semantic correctness. Lean Atlas defines *semantic hallucination* as the case where a formalization passes the type checker and may even have a completed proof, but is not semantically equivalent to the intended mathematical content. Its example is the sentence “3/2 = 1.5”: if a type annotation is omitted, Lean may default to `Nat`, producing `3 / 2 = 1`, which type-checks and can be proved, but is semantically wrong for the intended real-number statement. The paper identifies recurring patterns such as definition mismatch, missing or extra assumptions, goal substitution, quantifier/scope errors, and type-default semantics shifts [2604.16347].

Lean-GAP shows the same gap in a textbook exercise setting. Its pipeline finds that preprocessing and first-pass autoformalization can be largely automated, but verification remains “the most subtle and labor-intensive component,” requiring careful human oversight. The project therefore separates syntactic success from semantic fidelity and treats human sign-off, rather than elaboration alone, as the certification step [2606.02588].

## 3. Data-centric Atlas: lifting, synthesis, augmentation, and NL–FL corpora

"ATLAS: Autoformalizing Theorems through Lifting, Augmentation, and Synthesis of Data" addresses the corpus bottleneck by starting from a controlled concept repository lifted from Mathlib rather than from noisy web text or paraphrases of existing theorems. Its stated scope is undergraduate-level mathematics in Lean4 with Mathlib, organized into 13 domains, 55 topics, and 350 concepts curated from Mathlib’s undergraduate syllabus. The synthesis loop samples two concepts at random, asks a teacher model to generate a concise NL theorem integrating both, translates the theorem into Lean, parses the code into `theorem_name`, `theorem_variables`, `theorem_hypotheses`, and `theorem_conclusion`, compiles it with Lean’s REPL, repairs failures with a teacher model, and retains only semantically aligned pairs rated good or average by a separate alignment model. Verified pairs are then enlarged by two Lean-structure-aware augmentations: proof-step snapshots scraped from Infoview during tactic execution, and contraposition derived from `contrapose!` on individual hypotheses [2502.05567].

The training loop runs for 10 iterations. Each iteration samples 10,000 concept pairs and produces 10,000 NL statements. The student model is then fine-tuned for 3 epochs with cosine decay and learning rate `1e-5`, using student sampling parameters `top-p = 0.9` and temperature `0.6`. The abstract reports that, with 10 iterations, the framework constructs an undergraduate-level dataset comprising 117k theorem statements; the detailed system description presents the ATLAS dataset as 300k undergraduate-level NL–FL theorem statements. In both descriptions, the core claim is that a large verified corpus can be synthesized under compiler and teacher-model control rather than collected directly from naturally occurring aligned data [2502.05567].

The empirical outcome is a Lean4 translator with strong benchmark performance. On ProofNet, ATLAS Translator reaches `56.87%` pass@1, `80.59%` pass@8, and `92.99%` pass@128; on miniF2F it reaches `70.08%`, `91.60%`, and `96.93%`; on the 530-sample MathQual test subset it reaches `38.87%`, `65.47%`, and `84.72%`. The paper reports statistically significant improvements over both the HERALD Translator and the Kimina-Autoformalizer across all benchmarks in the abstract, and the detailed results show that synthetic-only training is already strong, while contraposition helps more than proof augmentation because proof correctness is harder to guarantee. A broader implication is that Atlas can be bootstrapped not only by direct textbook translation, but also by continually expanding verified statement corpora aligned with formal libraries.

## 4. Project-scale Atlas: verifier-in-the-loop compilation and proof repair

M2F reframes textbook autoformalization as project-scale knowledge compilation under a pinned environment $E$. The environment consists of the Lean toolchain plus a pinned dependency snapshot, and verification is exposed through file-level and project-level oracles:
$$\mathrm{VerifyProj}_E(\mathcal{P}) \to (ok,\Delta), \qquad \mathrm{VerifyFile}_E(\mathcal{P}, f) \to (ok,\Delta_f).$$
When a file verifies, goal states can be queried at a hole $h$ via
$$\mathrm{GoalState}_E(\mathcal{P}, f, h) \in \{(g,\Gamma), \bot\},$$
where $g$ is the goal type and $\Gamma = (x_1:T_1,\ldots,x_m:T_m)$ is the local context. Proof repair is measured by proof success rate
$$s = |H_{\mathrm{closed}}| / |H|,$$
with $H$ the matched-statement proof holes and $H_{\mathrm{closed}}$ the subset solved under $E$ [2602.17016].

The architecture is two-stage and is built around a single refinement primitive, VeriRefine. In Stage 1, statement compilation, long-form sources are normalized into JSON atomic blocks with provenance, a dependency DAG $G=(V,E)$ is inferred, and blocks are scheduled by a topological order $\tau$. For each block, an LLM proposes a Lean declaration skeleton such as `theorem ... := by sorry`, `lemma ... := by sorry`, `def ... := sorry`, or `instance ... := by sorry`. The file is compiled, and localized repairs are accepted only if Lean’s toolchain certifies strict improvement under a lexicographic objective that first reduces global error count and then localized error count. In Stage 2, proof repair, the project starts from compilable statements with frozen signatures; edits target only proofs and optional local helpers that do not change existing signatures. Candidate proof patches are goal-conditioned local edits, and acceptance is again lexicographic, this time minimizing file errors first and then the count of `sorry` holes outside comments and strings [2602.17016].

The practical significance is that M2F enforces monotone improvement. Each attempted patch causes exactly one invocation of `VerifyFileE`, and patches are committed only when the verifier confirms strict progress. The framework permits typed stubs to break cycles, stabilizes imports and namespaces per file, and can split oversized files into `sectionYY_partK.lean` fragments connected by a linear import chain. The article describing Atlas explicitly presents this methodology as a direct foundation for ingesting multiple textbooks into a coherent Lean library while preserving buildability and provenance [2602.17016].

The reported scale is textbook-level. In approximately three weeks, M2F converts 479 pages into a project-scale Lean library that builds end-to-end under the pinned environment: 241 files, 4,116 declarations, and 153,853 lines of Lean. The breakdown is 312 pages of *Real Analysis* into 49 files, 1,195 declarations, and 34,327 lines; 140 pages of *Convex Analysis* into 164 files, 2,620 declarations, and 105,682 lines; and a 27-page paper corpus into 28 files, 301 declarations, and 13,844 lines. Stage 1 achieves statement compile coverage `SCC = 100%` on all corpora, with average repair rounds `0.42/0.08/0.20`, and project buildability `PB` holds across corpora. Stage 2 closes `875/875` audited proof holes on the long-form corpora with `PSR = 100%`, and on FATE-H it achieves `96%` PSR fully automatic, compared with `80%` for Seed-Prover 1.5; with 31 declaration-level hints, it reaches `97%` PSR [2602.17016].

## 5. Library-scale production: multi-agent orchestration and cross-assistant realizations

The strongest claim that Atlas can function as a genuine library-building enterprise appears in "Formalizing Mathematics at Scale." There, AutoformBot treats textbook formalization as collaborative software engineering. A long-lived orchestrator builds a task DAG from the textbook, workers formalize ready targets in short-lived isolated git worktrees, reviewers inspect diffs and source context, a trace analyzer learns from failures and writes task-specific skill guides, and a supervisor runs a target-level evaluation harness after each merge. The infrastructure includes resource budgeting, pooled stateful sessions, batched merge queues with bisection, and an escalation protocol for true infrastructure failures [2605.29955].

The artifact produced by this system is Atlas as a collection of verified Lean 4 libraries from 26 open-access textbooks spanning analysis, algebra, topology and geometry, number theory, combinatorics, probability and statistics, PDEs, and theoretical computer science. The paper reports 2,855 successfully formalized targets out of 4,007, corresponding to `71.3%`, together with 483,918 lines of Lean code and over 45,000 declarations. Compute accounting is also explicit: 183,157 million tokens, with workers consuming `76.35% ± 5.71` of the compute distribution and smaller shares assigned to reviewers, the supervisor, orchestrator, full evaluation, readers, and analyzers. The evaluation harness grades matched targets by faithfulness, proof integrity, and code quality, each with threshold `≥ 3/5`, and augments build checks with structural tags such as `vacuous_body`, `returns_assumption`, `field_projection_body`, `custom_hypothesis_in_type`, `trivial_constructor`, and `orphan_class` [2605.29955].

A closely related Lean case study, "Automatic Textbook Formalization," demonstrates the same paradigm on a single 500+ page graduate textbook in algebraic combinatorics. The reported output is approximately 130,000 lines in 52 files and approximately 5,900 declarations, with all 340 selected target theorems and definitions proved in one week. The run used 30,046 total agent runs across roles: 85 sketchers, 8,704 provers, 6,467 maintainers, 6,797 math reviewers, 6,805 engineering reviewers, 550 triage agents, 307 scan agents, and 331 progress agents. The workflow is trunk-based, with short-lived feature branches, two independent reviews per PR, and a single merge queue that serializes integration to keep `main` building [2604.03071].

Atlas-like production is not confined to Lean. "Munkres’ General Topology Autoformalized in Isabelle/HOL" reports 85,472 lines of Isabelle/HOL across four chapter files, with 199 definitions, 806 lemmas/theorems/corollaries, and zero `sorry`s, covering all 39 sections of Munkres’ *Topology* in 24 active days. Its methodology is a "sorry-first" declarative proof workflow coupled with bulk use of `sledgehammer`, `process_theories`, explicit unfolding, and aggressive proof profiling via `eval_at -t`. A separate Megalodon experiment reports 160k lines of formalized topology by January 4, 2026, with about 130k lines produced in two weeks for an LLM subscription cost of about `$100`, including more than 1.5k lemmas/theorems and long proofs of Urysohn’s lemma, Urysohn’s metrization theorem, and the Tietze extension theorem. Together these results support a plausible inference: Atlas is not tied to a single proof assistant, even though current large-scale instantiations are strongest in Lean [2604.07455][2601.03298].

## 6. Semantic alignment, governance, and persistent limitations

A central misconception in large-scale autoformalization is that kernel verification alone certifies a textbook library. The recent literature rejects this. Lean Atlas introduces *aligned Lean code* as code whose propositions and definitions have undergone human semantic verification in addition to type checking. Its Lean Compass algorithm operates on a project-specific dependency graph $G=(V,E)$ whose edges are classified by source kind, dependency site, and target kind. Compass prunes theorem-value edges, computes the affecting set
$$A(T)=\{v \in V \mid \exists \text{ path } t \to v \text{ in } G' \text{ with } t \in T\}\cup\{\text{axioms}\},$$
and measures reduction by
$$R(m)=1-|A(\{m\})|/|RC(m)|.$$
The empirical reductions are substantial for proof-heavy projects: PrimeNumberTheoremAnd achieves `99.1–99.7%` per-target reductions, Carleson averages `96.2%`, and Brownian Motion averages `94.4%`; the FLT milestone subset averages `59.8%`, PhysLib `69.0%`, and the definition-heavy XMSS project `27.3%` [2604.16347].

Lean-GAP operationalizes a complementary governance stack for textbook exercises. It releases 430 PhD-reviewed formalized problems from 1,966 exercises in Dummit and Foote, uses standardized naming keys `DF_{sec}_{subsec}_{exercise_num}`, and requires a two-stage human review in which a contributor prepares an informal rewrite plus Lean declaration and an independent maintainer performs semantic review. Automated filters remain triage tools only: CI elaboration, suspicious-pattern filters `C1–C11`, and an LLM judge scoring five axes `S1` through `S5` for objects, hypotheses, conclusion, structure, and specificity. The compiler-grounded agent loop reaches `95.5%` any-pass elaboration on all 1,966 exercises, but semantic evaluation remains materially weaker, with mean LLM-judge scores of `3.56` for the Codex loop and `3.45` for GPT-5, and recurrent problems including `unknownIdentifier`, `synthInstanceFailed`, vacuous existentials, trivial `True` conclusions, and missing hypotheses such as the omitted condition `2 ≤ n` in Exercise 2.3.21 [2606.02588].

The limitations reported across Atlas-related work are consistent. M2F notes that complex, highly parameterized proofs may require better global planning than local diagnostic repair, and that typed stubs can defer semantic misalignments into Stage 2. ATLAS remains bounded by Mathlib’s implemented definitions and by teacher-model priors in NL generation and semantic alignment. AutoformBot identifies missing foundations in Lie theory and sophisticated geometry as a major source of partial coverage and diminishing returns. Lean Atlas underperforms in definition-heavy domains because value-level semantics reside in chains of definitions that cannot be pruned aggressively. Lean-GAP emphasizes library drift and coverage gaps, especially in advanced algebra. The common conclusion is not that Atlas is infeasible, but that buildability, proof closure, and semantic faithfulness are distinct objectives that require different mechanisms and different acceptance criteria [2602.17016][2502.05567][2605.29955][2604.16347][2606.02588].

Taken together, the current Atlas literature describes an emerging stack for large-scale mathematical formalization. Data-centric systems enlarge the supply of verified NL–FL statements; verifier-in-the-loop systems make textbook-length sources compile and then repair proofs under fixed signatures; multi-agent orchestrators turn shared repositories into high-throughput formalization environments; and semantic-review tools constrain the gap between formal correctness and intended mathematics. The mature form of Atlas, as these papers collectively imply, is a continuously growing, dependency-governed, semantically audited library of textbook mathematics rather than merely a collection of elaborating files.

Source: https://www.emergentmind.com/topics/autoformalized-textbook-library-at-scale-atlas