Papers
Topics
Authors
Recent
Search
2000 character limit reached

130k Lines of Formal Topology in Two Weeks: Simple and Cheap Autoformalization for Everyone?

Published 6 Jan 2026 in cs.LO, cs.AI, and cs.SC | (2601.03298v1)

Abstract: This is a brief description of a project that has already autoformalized a large portion of the general topology from the Munkres textbook (which has in total 241 pages in 7 chapters and 39 sections). The project has been running since November 21, 2025 and has as of January 4, 2026, produced 160k lines of formalized topology. Most of it (about 130k lines) have been done in two weeks,from December 22 to January 4, for an LLM subscription cost of about \$100. This includes a 3k-line proof of Urysohn's lemma, a 2k-line proof of Urysohn's Metrization theorem, over 10k-line proof of the Tietze extension theorem, and many more (in total over 1.5k lemmas/theorems). The approach is quite simple and cheap: build a long-running feedback loop between an LLM and a reasonably fast proof checker equipped with a core foundational library. The LLM is now instantiated as ChatGPT (mostly 5.2) or Claude Sonnet (4.5) run through the respective Codex or Claude Code command line interfaces. The proof checker is Chad Brown's higher-order set theory system Megalodon, and the core library is Brown's formalization of basic set theory and surreal numbers (including reals, etc). The rest is some prompt engineering and technical choices which we describe here. Based on the fast progress, low cost, virtually unknown ITP/library, and the simple setup available to everyone, we believe that (auto)formalization may become quite easy and ubiquitous in 2026, regardless of which proof assistant is used.

Authors (1)

Summary

  • The paper presents a novel autoformalization pipeline that converts 130k lines of topology text into formal proofs in 14 days at a cost below $100.
  • It leverages an efficient feedback loop between commercial LLM coding interfaces and the Megalodon proof assistant to automate formalization with minimal human intervention.
  • Key results include full formalizations of major theorems and robust error recovery mechanisms, demonstrating scalable and cost-effective formal mathematics.

Large-Scale Autoformalization of Topology: Methods, Achievements, and Implications

Project Overview and Motivation

"130k Lines of Formal Topology in Two Weeks: Simple and Cheap Autoformalization for Everyone?" (2601.03298) documents an unprecedented autoformalization effort that formalized over 130,000 lines of the topology content from Munkres' standard textbook in 14 days, at a subscription LLM cost of approximately \$100. This was achieved not by relying on specialized or proprietary toolchains but by constructing an efficient feedback loop between commercial LLM coding interfaces (ChatGPT/Codex 5.2 and Claude Sonnet 4.5) and the higher-order set-theoretic proof assistant Megalodon, augmented with minimal but judicious prompt engineering and automation.

This work exemplifies an end-to-end pipeline for informal-to-formal translation of mainstream mathematical text using only commodity AI infrastructure and a publicly available but previously obscure ITP. The experiment's central claims are that large-scale autoformalization is now operationally trivial and affordable for non-experts, and that the performance of high-quality LLMs in long-feedback cycles significantly lowers traditional barriers in formal mathematics.

System Architecture and Experimental Protocols

The pipeline operationalizes autoformalization by establishing the following sequence:

  • Frontend LLM Agent: A shell-isolated instance of the LLM coding interface (OpenAI Codex or Claude Code) operates continuously in a Linux sandbox (bubblewrap), driven by prompt automation scripts that feed a stable, minimal instruction prompt after every task completion.
  • Proof Engine: The backend is the Megalodon higher-order set-theory proof checker, initialized with Chad Brown's base library for set theory and surreal numbers. Most library proofs are removed and replaced by "admit" placeholders, retaining only a few exemplars to provide the LLM necessary proof reference material.
  • Workflow Rules: A codified instruction file (CLAUDE.md) strictly specifies editable code regions, preservation of work, prohibition of duplicate axioms, and priorities for replacing admits with actual proofs and focusing on canonical theorems.
  • Automation and Monitoring: Scripts monitor LLM session activity via tmux and inject prompts automatically to keep the agent productive and avoid idle time. The use of cost- and usage-tracking utilities, theorem dependency extractors, and backup diff logs provides fine-grained project control.
  • Interventions: While the system is largely unsupervised, the experimenter retained the ability to inject high-priority tasks, e.g., directing proof focus to the Urysohn lemma or Tietze extension when LLM drift or local minima was observed.

Achievements and Quantitative Results

The project formalized essentially the entire spectrum of Munkres topology at scale. Key strong results include:

  • Volume and Coverage: Over 160,000 lines were produced by January 4, 2026, with 130,000 in just two weeks. More than 1,500 named lemmas/theorems are stated and (mostly) proved.
  • Major Theorems: Full formalizations (with complete proofs, no admits) of the Urysohn Lemma (3,000 lines), Urysohn Metrization Theorem (2,000 lines), and Tietze Extension Theorem (over 10,000 lines for its core case), among many others.
  • Automated Progress on Challenging Theorems: For instance, the LLM autonomously discovered that to complete Step II of the Tietze proof, formalization of metric space completeness and uniform limits was necessary—requiring substantial infrastructure refactoring and generalization outside the order of the textbook. Ultimately, the system generated the full functional/infinite-step proof and, as a corollary, all standard variants of the Tietze theorem.
  • Minimal Supervision: Prompting needs were reduced to near zero with prompt-loop automation; only bottlenecks (context drift, long proofs, forward-reference deadlocks) required human intervention.
  • Cost Effectiveness: The total LLM usage cost for this scale of formalization is claimed to be below \$100, primarily utilizing subscription-based API access rather than metered per-query billing.

Contradictory to some prior expectations, the system demonstrates that advanced LLMs—when coupled with even limited domain-specific context, minimal scripting, and a classical proof assistant—are capable of sustaining deep, semantically consistent mathematical development, including robust handling of object dependencies, proof obligation discharge, and error recovery even across arbitrarily lengthy scripts.

Methodological Analysis and System Behavior

This autoformalization protocol required innovations in several operational dimensions:

  • Feedback Loop Tuning: The interplay between LLM agent and proof checker was carefully managed to avoid context window overflow, catastrophic forgetting, or logic system drift. Isolation in the bubblewrap shell permitted us to maximize LLM API autonomy without risk.
  • Prompt Engineering: The CLAUDE.md "rules file" was continuously updated to encode best practices, error corrections (such as the avoidance of accidental mass deletions), and dependency tracking practices. This evolved iteratively in response to observed LLM behavior (e.g., excessive work on stubs rather than hard theorems).
  • Proof Refactoring and Compactification: As file size reached hundreds of thousands of lines and Megalodon verification slowed, the agent exhibited capacity for proof factorizations and infrastructural abstraction, albeit limited by the system's internal context memory and necessitating occasional resets.
  • Dependency Tracking and Progress Monitoring: Scripts computed proof dependency graphs and flagged recursively admitted (not-yet-formalized) theorems, thereby guiding the agent to close critical gaps. Notably, uniform-limit machinery and metric completions had to be moved forward, breaking from textbook linearity.

Theoretical and Practical Implications

This experiment provides rigorous empirical evidence that broad portions of standard mathematical scholarship can now be formalized rapidly and with limited expert intervention. The following implications are especially salient:

  • Proof Assistant Agnosticism: Success did not depend on high-resource or widely publicized proof assistants. Megalodon, a higher-order set-theory system with minimal LLM exposure, was sufficient; the LLM generalized its internal representation of Megalodon syntax, logic, and proof patterns from a small set of provided examples.
  • Economic Accessibility: The total cost profile is competitive even with graduate student labor on similar projects, and the resource requirement is primarily cloud LLM subscription, rather than traditional infrastructure or human-in-the-loop curation.
  • Scalability and Automation: Prompt-loop automation and minimal but targeted scripting allow for projects of scale (textbook/chapter length) to proceed without continuous human "babysitting," lowering the barrier for individual researchers and democratizing formalization.
  • Coding Agent Robustness: Commodity LLM coding agents demonstrated resilience under long-running proof construction, nontrivial file manipulations, and recovery from significant logical or contextual errors with only lightweight intervention.

Challenges and Limits

Despite strong results, several challenges were observed:

  • Session Compactification: LLM session state files eventually reached hard limits, necessitating manual resets and deliberate context re-initialization to preserve project progress. Native mechanisms for session compactification and memory management remain inadequate for extremely long-running sessions.
  • LLM Tendency Toward Local Minima: Agents could become "distracted" (e.g., focusing on simple exercises, redundant refactorings, or repeated expansion instead of abstraction), requiring explicit override prompts to reallocate focus to rich theorems.
  • Forward Reference and Textbook Nonlinearity: Key theorems sometimes required moving prerequisite machinery (e.g., metric completeness) forward out of textbook order, which the LLM eventually accomplished but only after costly detours and substantial trial-and-error.
  • Proof Checking Scalability: File-based verification with Megalodon slowed as the library grew. Future work will require file modularization or proof admission pragmas to scale to even larger corpora.

Prospects for Future AI-Augmented Formalization

The demonstrated pipeline points toward a future where fully automated, end-to-end autoformalization of complex mathematical domains is routine. Expected future directions include:

  • Integration with Optimized Orchestration: Adapting orchestration tools to further minimize prompt drift, dynamically balance theorem proving effort, and learn optimal task routing policies.
  • Generalization to Further Domains: Extending the same methodology to textbooks in algebra, analysis, geometry, and logic, thus rapidly increasing the body of formally certified mathematics.
  • Proof Synthesis and High-Level Abstraction: Encouraging the LLM to generate not only mass formalizations but also higher-level, reusable proof strategies, further increasing the impact on verification and discovery.
  • Collaboration and Evaluation Benchmarks: Parameterized, reproducible pipelines may become new benchmarks for both formalization research and evaluation of next-generation LLMs in mathematical reasoning.

Conclusion

The results in "130k Lines of Formal Topology in Two Weeks: Simple and Cheap Autoformalization for Everyone?" (2601.03298) indicate that AI-driven autoformalization has reached a level of practical maturity permitting rapid, large-scale, low-cost translation of mainstream mathematical text into formal, machine-checked proofs. The methodology is minimally reliant on sophisticated infrastructure or high-maintenance orchestration, instead harnessing LLM progression and classical proof checking in a tightly coupled feedback loop. These results commit the autoformalization community to further investigate cost, scale, and reliability, and demonstrate that the era of democratized, AI-augmented formal mathematics is now a reality.

Whiteboard

Explain it Like I'm 14

Overview

This paper describes a simple, low-cost way to turn a math textbook into precise, computer‑checked proofs very quickly. The author set up a long-running “work loop” between:

  • a LLM (an AI that writes and edits code), and
  • a proof checker (a program that acts like a strict math referee).

Using this setup, the project autoformalized a large part of the general topology textbook by Munkres (a famous math book), producing around 160,000 lines of formal math code by early January 2026—about 130,000 lines in just two weeks. It includes complete formal proofs of some major, famously difficult theorems in topology.

Objectives and Questions

The project aimed to answer simple, practical questions:

  • Can we use an AI coding agent plus a fast proof checker to turn math from a textbook into computer‑verified proofs at scale?
  • Can this be done cheaply (about $100–$200 per month in subscriptions) and with simple tools that anyone can set up?
  • Will the AI be able to handle not just easy definitions, but also long, famous theorems?
  • What rules and routines help the AI stay focused, avoid mistakes, and keep making progress?

Methods and Approach

Think of the setup like a small factory with two main machines:

  1. The AI coder (ChatGPT or Claude, used through coding command-line tools)
    • It reads instructions and writes math “code” in a language called Megalodon (a proof assistant that checks higher‑order set theory).
    • It adds definitions, states theorems, and writes detailed proofs.
  2. The proof checker (Megalodon)
    • It is like a super-strict math referee. If the proof is perfect, it stays silent. If something is wrong, it complains with an error message.
    • The AI then fixes the errors and tries again.

To keep everything safe and organized:

  • The AI was run inside a “sandbox” (a safe, isolated area) so it couldn’t accidentally break things on the computer.
  • The author used a terminal tool (tmux) to keep the session running for days and automatically re-prompt the AI if it paused.
  • A short instruction file (CLAUDE.md) acted like an “employee handbook” for the AI, with strict rules:
    • Only edit the topology section of the big math file.
    • Don’t throw away useful work.
    • Make frequent backups with summaries of changes.
    • Run the proof checker often.
    • Track which theorems depend on which other theorems (so the AI can focus on bottlenecks).
  • Occasionally, the author gave “focus prompts” (for example, “finish Urysohn’s Lemma before touching anything else”) to push through major theorems without distractions.
  • The team tried a “hammer” tool (an automated theorem prover) to help solve subproblems, but it wasn’t very helpful yet without extra infrastructure.

In everyday terms: the AI writes math, the referee checks it, the AI fixes errors, and this repeats for hours—like a feedback loop that steadily grows a verified math library.

Main Findings and Results

What was achieved:

  • About 160,000 lines of formal topology code by January 4, 2026, including about 130,000 lines in two weeks.
  • Over 1,500 lemmas and theorems fully proven.
  • Complete formal proofs of several famous, challenging results, such as:
    • Urysohn’s Lemma: In “nice” topological spaces, you can build a continuous function that separates two closed sets. Why it matters: it’s a building block for deeper results and helps relate shapes/spaces to functions.
    • Urysohn’s Metrization Theorem: This tells us when a space can be described by distances (like in geometry). Why it matters: it connects abstract topology to familiar metric spaces.
    • Tietze Extension Theorem: If you have a continuous function defined on a “closed” part of a space, you can extend it to the whole space without breaking continuity. Why it matters: it’s powerful for constructing functions with desired properties across whole spaces.

Why this is important:

  • It shows that a straightforward AI + checker loop can tackle textbook-level math quickly, including long and subtle proofs, using a relatively unknown proof assistant (Megalodon) and a simple setup.
  • The costs were low compared to the scale of the output. While subscription costs were modest (around $100–$200), separate usage tracking suggested higher API costs; this mismatch raises questions about pricing policies, but the main takeaway is that “subscription mode” can be very cost-effective.
  • The process improved with clear rules, frequent checks, backups, and dependency tracking.

Challenges discovered:

  • AI memory limits: long sessions eventually hit a “context compactification” limit, forcing occasional resets or creative session management.
  • The AI sometimes favored easy tasks unless guided to focus on major theorems.
  • Proof checking gets slower as the file grows, but it remained manageable.
  • The “hammer” tools need better integration (like caching and smarter problem selection) to be truly helpful.

Implications and Potential Impact

Big picture: This work suggests that autoformalization—turning math textbooks into verified, computer-checked proofs—could become common and accessible in 2026. With an affordable subscription, basic sandboxing, a proof assistant, and a simple feedback loop, many people could:

  • Build large, reliable libraries of formal math much faster than before.
  • Reduce human error in proofs.
  • Teach and learn with precise, checkable examples.
  • Make advanced math more shareable and reusable (computers can instantly verify and link results).

Future improvements might include better session management for AI memory, smarter use of automated theorem provers, and clearer “best practices” for large formalization projects. But even with today’s tools, this project shows that a simple, disciplined workflow can produce a lot of high-quality, verified math quickly and cheaply.

Knowledge Gaps

Unresolved gaps, limitations, and open questions

Below is a single, concise list of what remains missing, uncertain, or unexplored in the paper. Each item is written to be concrete and actionable for future researchers.

  • Coverage and completeness metrics are missing: there is no quantitative summary of how many of the 39 sections (and their exercises) are fully formalized, how many theorems are still admitted, and the per-section admit footprint.
  • Faithfulness to the textbook is not audited: the extent to which formal statements exactly match Munkres’ generality and hypotheses (versus ad‑hoc or simplified stubs) is unknown; no systematic cross-checking tool or process is described.
  • Soundness risk from admitted pre-topology library: many core set-theoretic and real-number results were “admitted” in the foundational library; the cumulative reliance on these admits and the plan to discharge them is not quantified.
  • Dependency “choke point” strategy is ad hoc: while a simple dependency tracker exists, there is no automated method to identify and prioritize the minimal set of admits whose proofs would eliminate the most recursive admits downstream.
  • Generalization across proof assistants is untested: claims of broad applicability are not supported by replications or ablations in Lean, Isabelle/HOL, Coq, or other mainstream ecosystems.
  • Model and prompt ablations are absent: the impact of LLM choice (ChatGPT vs Claude), reasoning mode (high vs extra high), prompt styles, and session length on formalization quality and throughput is not systematically evaluated.
  • Hammer (aby) integration is incomplete: caching, premise selection, robust ATP re-run orchestration, and proof reconstruction are missing; the net benefit of hammer assistance versus direct LLM proofs is unevaluated.
  • Session compactification is opaque and brittle: the agent’s context management and hard session limits are proprietary and unpredictable; the effect of reset strategies (rewriting the session file) on progress and proof quality is unmeasured.
  • Cost accounting is unclear: large discrepancies exist between subscription-reported costs and external usage reports; true token consumption, cost-per-line, and cost-per-proof metrics are missing, hindering reproducibility budgeting.
  • Sandbox robustness is not assessed: path/data confusion incidents are noted, but no evaluation of sandbox policies, I/O constraints, or standardized isolation profiles is provided to ensure safe, reliable automation.
  • Proof maintainability is unexamined: very large proofs (e.g., 10k lines) lack analysis of modularity, redundancy, or refactoring opportunities; no guidelines or tooling are proposed for reducing proof size while preserving readability.
  • Verification scaling is not addressed: Megalodon run-time growth (to ~32s per build at ~170k lines) is noted, but strategies like file-splitting, modular compilation, or admitted “final” proofs are neither implemented nor evaluated.
  • Cross-verification is absent: there is no independent checking (e.g., via a second proof assistant or verified export) to rule out tool-chain bugs or unintended reliance on admits.
  • Automated detection of incorrect/narrow definitions is missing: given early tendencies to create stubs/special cases, no static analyses or linting pipelines enforce generality and prevent hidden overfitting.
  • Planning and progress tracking are ineffective: the proposed PROGRESS files had mixed compliance; there is no demonstrated mechanism that reliably enforces balanced advancement across sections versus deep focus on hard theorems.
  • Human-in-the-loop parameters are unknown: the minimal level of supervision, intervention frequency, and their quantitative impact on throughput and correctness are not measured.
  • Portability to mainstream libraries is unexplored: no investigation of translating Megalodon proofs into Lean/Isabelle/Coq or aligning with mathlib standards and notations is provided.
  • ATP re-run orchestration is lacking: there is no incremental or dependency-aware strategy to re-run ATPs only when needed, leading to potential inefficiency or stale results.
  • Foundations for real analysis need auditing: although some real-number completeness results (e.g., R_lub_existsR\_lub\_exists) were proved, the broader reliance on surreal-number-based constructions and their adequacy for all topology sections is not fully validated.
  • Correctness beyond compilation is not measured: no semantic testing (e.g., model-based checks, counterexample search), robustness checks, or proof-quality metrics are reported.
  • Duplicate/overlapping content control is weak: the LLM is warned to avoid duplicates, but there is no automated tooling to detect duplicated definitions/theorems or inconsistent variants.
  • Provenance mining is undeveloped: comprehensive logs exist but there are no tools to extract failure modes, derive better prompts, or automate retrospective analyses for continuous improvement.
  • Security assessment of agent capabilities is absent: allowing “unlimited powers” inside the sandbox lacks a formal risk analysis and mitigation plan beyond isolation.
  • Exercise coverage and utility are under-characterized: exercises were deprioritized; how this affects infrastructure or key dependencies is not evaluated.
  • Domain generalization is untested: results are limited to topology; performance and challenges in algebra, analysis, category theory, or logic are unknown.
  • Guardrail enforcement is weak: focused prompts occasionally led to “forbidden tricks”; stronger constraint enforcement and violation detection mechanisms are not described.
  • Baseline metrics are missing: tokens-per-line, time-per-proof, admit-elimination rate, and throughput under different settings are not reported, impeding comparative studies.
  • ML premise selection is not integrated: neither the hammer nor the LLM loop uses trained premise selectors to guide proof search and dependency management.
  • Reproducibility instructions are incomplete: although code and logs exist, a step-by-step artifact (environment, scripts, versions, session management, prompts) for exact replication is not provided.
  • Informal–formal alignment tooling is absent: while comments link to topology.tex, there is no automated checker that validates one-to-one alignment of definitions, hypotheses, and conclusions.
  • Alternative foundations are untested: behavior with type-theoretic or constructive logics is unexplored; the impact of foundational choices on autoformalization difficulty and proof size is unknown.
  • Orchestration tooling is brittle: the tmux-based prompt feeder is a simple heuristic; more robust, event-driven orchestration (with failure detection, retries, and backoff) is not evaluated.
  • Admit-elimination strategy is ad hoc: there is no prioritized schedule, tracking dashboard, or SLA-like goals for turning admits into proofs across the corpus.
  • Impact of session resets is unknown: rewriting the session to an earlier snapshot is unsupported; its effects on knowledge retention, error rates, and proof redundancy are not measured.

Practical Applications

Immediate Applications

Below is a concise set of actionable use cases that can be deployed now, derived from the paper’s workflow, tools, and initial results.

  • Academic: rapid autoformalization of textbook chapters and lecture notes
    • Sector: Education, Academia
    • What: Use the paper’s simple LLM–proof-checker loop (ChatGPT/Claude Code + Megalodon) to convert existing course materials (e.g., topology, analysis, algebra) into formally verified libraries with HTML cross-linking for student use.
    • Tools/Workflow: bwrap-sandboxed coding agent; tmux session manager; CLAUDE.md work-instructions; Megalodon checker; mgwiki HTML publishing; backup and progress files; mgdeps6.pl dependency dashboard.
    • Assumptions/Dependencies: Access to an LLM subscription; minimal trusted core library; faculty TA time to set up and curate; acceptance of Megalodon (or adapter to Lean/Coq/Isabelle); manageable file sizes or splitting for verification performance.
  • Academic: formal verification of small research claims and workshop papers
    • Sector: Academia
    • What: Pilot “proof sprints” for small/medium-sized papers, leveraging focused prompting (e.g., Urysohn/Tietze) and gradual admits elimination.
    • Tools/Workflow: “Focused prompting day” template; numbered backups; dependency tracking to identify “choke points”; Megalodon compile checks.
    • Assumptions/Dependencies: Author participation to translate informal statements into precise definitions; core library adequacy; model reliability; session length limits managed via resets.
  • Education: interactive formal textbooks publicly accessible online
    • Sector: Education, Software
    • What: Publish autoformalized chapters in a cross-linked HTML format (mgwiki) for browsing and learning; integrate exercises as formal stubs students can complete.
    • Tools/Workflow: mgwiki HTML pipeline; CLAUDE.md rules to prevent library damage; exercise-stub labeling and admit tracking.
    • Assumptions/Dependencies: Institutional willingness to host; student training in proof assistant syntax; moderation of LLM changes via sandbox and backups.
  • Software engineering: sandboxed autonomous coding agents for safe proof/code generation
    • Sector: Software, Security
    • What: Adopt the bwrap isolation pattern to let agents invoke tools safely for proof generation and code refactoring, minimizing risk to host systems.
    • Tools/Workflow: bwrap sandbox; tmux logging; periodic backups; cost monitoring (ccusage or equivalent); CI hooks to run proof checker on change.
    • Assumptions/Dependencies: Security sign-off; careful mapping of directories; reliable backup policies; agent confusion handled via instructions and logging.
  • Research ops: low-cost “AutoFormalization Kit” for labs
    • Sector: Academia, Research IT
    • What: Package the scripts and prompts (tmux auto-prompt feeder, CLAUDE.md rules, mgdeps6.pl, HTML publishing) to bootstrap formalization projects in under a day.
    • Tools/Workflow: Containerized setup; one-click tmux + bwrap + Megalodon + LLM CLI; templates for PROGRESS and CHANGES files.
    • Assumptions/Dependencies: Lab Linux environment; LLM plan budget ($20–$200/month); maintainers to keep core library trusted segments stable.
  • QA/reproducibility: “ProofOps” CI for formalization repositories
    • Sector: Software, Academia
    • What: Add Megalodon (or other proof assistants) to CI pipelines to reject regressions, monitor admits, and publish HTML snapshots per commit.
    • Tools/Workflow: CI scripts calling proof checker; mgdeps6.pl status badges; HTML artifact uploads.
    • Assumptions/Dependencies: Proof assistant compatibility in CI; reasonable verification times; split large files if needed.
  • Documentation-to-spec formalization pilots
    • Sector: Industry (software, protocols), RegTech
    • What: Translate critical portions of internal specifications into formal statements and machine-checked proofs (e.g., invariants for small protocols, API contracts).
    • Tools/Workflow: LLM agent with strict work-instructions; “trusted pre-spec” section; admits flagged for review; dependency tracking for risk focus.
    • Assumptions/Dependencies: Domain experts to validate formal statements; limited scope to keep costs manageable; choice of assistant aligned with industry toolchain.
  • Cost and usage telemetry for LLM-assisted formalization
    • Sector: Software, Finance (internal budgeting)
    • What: Monitor and optimize LLM usage using hourly reports; compare subscription vs. API costs; set quotas per project; identify cost anomalies early.
    • Tools/Workflow: ccusage-style tracking; scheduled reports; “focused prompting” to minimize wasted turns.
    • Assumptions/Dependencies: Transparent billing by providers; internal dashboards; organizational budgeting practices.
  • Security policy prototypes for AI agent operations
    • Sector: Policy, Security
    • What: Draft immediate sandboxing and logging guidelines for AI coding agents doing long-running tasks (isolation, backups, tamper-evident logs, access control).
    • Tools/Workflow: bwrap isolation profile; tmux logging retention; periodic backups and wc checks to detect accidental loss; CHANGES justification policy.
    • Assumptions/Dependencies: Organizational acceptance; alignment with existing security standards; training for engineers.
  • Teaching assistants augmented by LLM for routine lemmas/exercises
    • Sector: Education
    • What: Reduce TA workload by autoformalizing routine exercises and infrastructure lemmas; TAs focus on conceptual issues and hard proofs.
    • Tools/Workflow: CLAUDE.md rules; dependency dashboards to identify blockers; admit triage; periodic Megalodon runs.
    • Assumptions/Dependencies: TA oversight; course alignment; consistency across chapters.

Long-Term Applications

The following opportunities likely require further research, engineering, scaling, or ecosystem development before broad deployment.

  • National-scale formal mathematics initiative
    • Sector: Policy, Academia
    • What: Fund and coordinate a program to autoformalize foundational university curricula (analysis, algebra, topology, probability) into open, verified libraries.
    • Tools/Workflow: Standardized “handbook of good formalization practices”; cross-assistant adapters (Lean/Coq/Isabelle/Mizar/Megalodon); quality gates; public HTML portals.
    • Assumptions/Dependencies: Stable funding; community governance; IP clearance for textbooks; interoperability standards.
  • Safety-critical formal verification in industry
    • Sector: Healthcare, Aerospace, Automotive, Energy
    • What: Adopt autoformalization workflows for specifications and proofs in device control, protocols, and certification reports; integrate with model-based design.
    • Tools/Workflow: Stronger hammers with proof reconstruction; domain-specific libraries; CI/CD “ProofOps”; auditing dashboards for admits and dependencies.
    • Assumptions/Dependencies: Regulatory acceptance; robust proof reconstruction; domain ontology formalization; staff training.
  • Smart contracts and quantitative finance formalization
    • Sector: Finance, Web3
    • What: Formalize contract logic and risk models; auto-generate proofs of invariants (e.g., no double-spend, collateral safety) and compliance properties.
    • Tools/Workflow: Assistant adapters for solidity/spec DSLs; mapping docs to formal specs; dependency tracking for economic assumptions.
    • Assumptions/Dependencies: Domain-specific semantics; community standards for formal proof acceptance; scalable verification for large codebases.
  • AI tutor systems with formal proof grounding
    • Sector: Education, Software
    • What: Interactive textbooks and tutors that explain, verify, and adapt proofs; students modify formal stubs; automated feedback grounded in machine-checked reasoning.
    • Tools/Workflow: Frontend UI on top of mgwiki-like portals; proof snippets as exercises; scaffolding via dependency graphs; gamified progression.
    • Assumptions/Dependencies: Usability research; classroom integration; content licensing; performance scaling of checkers.
  • Large-scale formal knowledge graphs powering search and reasoning
    • Sector: Software, Research
    • What: Build structured, verified knowledge graphs from autoformalized math; enable query, recombination, and automatic theorem reuse for new domains (e.g., ML, optimization).
    • Tools/Workflow: Cross-prover interop; ontology alignment; proof-term indexing; ATP-backed retrieval with reconstruction.
    • Assumptions/Dependencies: Standard formats; advances in premise selection and caching; compute budgets for large repositories.
  • Agent safety and operational standards
    • Sector: Policy, Security
    • What: Codify best practices for long-running autonomous agents (sandboxing, logging, backups, session reset policies, cost governance), formalized as compliance checklists.
    • Tools/Workflow: Reference isolation profiles; cost/usage contracts; auditability standards; “do-not-edit” rule enforcement akin to CLAUDE.md.
    • Assumptions/Dependencies: Consensus on standards; regulator buy-in; vendor cooperation on telemetry and controls.
  • Cross-assistant portability and benchmarking
    • Sector: Academia, Software
    • What: Systematic ablations across models and proof assistants; adapters to reuse the LLM-loop in Lean/Coq/Isabelle; shared metrics on admits, proof length, dependency health.
    • Tools/Workflow: Adapter layers; common dependency trackers; benchmark suites (textbook-to-library tasks).
    • Assumptions/Dependencies: Community effort; open datasets/logs; comparability despite assistant idiosyncrasies.
  • Robust session management and context compaction research
    • Sector: Software, LLM research
    • What: Solve hard limits of long sessions; design principled compaction and state handoffs; persistent “agent memory” compatible with formalization workflows.
    • Tools/Workflow: External state stores (proof state, unresolved admits); teaching agents to resume via structured “status snapshots”.
    • Assumptions/Dependencies: LLM provider APIs supporting state injection; reliability of external memory; privacy/security of logs.
  • Better hammers and proof reconstruction for higher-order settings
    • Sector: Automated Reasoning, Software
    • What: Improve ATP export (TH0 TPTP), premise selection, caching, and reconstruction so LLMs offload fine-grained proof steps reliably.
    • Tools/Workflow: Hybrid LLM–ATP loop; proof-term minimization; auto-reruns on change with smart caching.
    • Assumptions/Dependencies: Advances in reconstruction; scalable caching strategies; consistent translation to FOF/HO logics.
  • Verified foundations for applied math in ML and control
    • Sector: AI/ML, Robotics
    • What: Extend formal libraries through topology to functional analysis, measure theory, and control; enable verified convergence and stability proofs for algorithms.
    • Tools/Workflow: Pipeline replicating textbook coverage; dependency tracking to prioritize key bottlenecks (e.g., completeness of reals).
    • Assumptions/Dependencies: Significant expansion of libraries; domain collaboration; performance improvements in proof checkers.
  • Formalization-driven research reproducibility
    • Sector: Academia, Policy
    • What: Encourage journals and funders to accept/require machine-checked proofs for theoretical contributions; provide workflows and templates for authors.
    • Tools/Workflow: Submission packages with HTML proof portals; CI-verified repositories; audit trails of admits removed over time.
    • Assumptions/Dependencies: Cultural change; onboarding support; practical guidelines for scope and exceptions.
  • Commercial “AutoFormalization Cloud” offerings
    • Sector: Software
    • What: Managed service providing agents, sandboxing, proof assistants, publishing, telemetry, and expert review to deliver formalized content at predictable cost.
    • Tools/Workflow: Multi-tenant agent orchestration; per-project dashboards; SLA-backed verification pipelines.
    • Assumptions/Dependencies: Reliable cost models; talent for expert oversight; integration with customer toolchains.
  • Formalization of regulatory texts into machine-checkable compliance
    • Sector: Policy, RegTech
    • What: Map rules (e.g., safety constraints, financial compliance) to formal predicates and proofs, enabling automated checks on systems and workflows.
    • Tools/Workflow: Domain ontologies; LLM-assisted mapping from prose to formal contracts/specs; dependency dashboards for rule coverage.
    • Assumptions/Dependencies: Legal validation; standards for formal semantics of regulation; interfaces to operational systems.

Glossary

  • Accumulation point: A point where every neighborhood contains infinitely many points of a given set (a limit point). "compact_space_net_has_accumulation_point"
  • Autoformalization: The use of AI/ML systems to translate informal mathematics into formal proofs and definitions in a proof assistant. "I have been working (more or less seriously) with my colleagues on learning-assisted autoformalization since 2014"
  • Automated reasoning: The study and practice of using computers to reason about logical statements and prove theorems automatically. "Theory of computation~Automated reasoning"
  • Automated theorem proving (ATP): Algorithms and systems that automatically attempt to prove mathematical theorems from axioms. "feedback loops in ATP and conjecturing"
  • Basis (topology): A collection of open sets such that every open set can be written as a union of basis elements. "order_topology_basis_is_basis"
  • Box topology: The topology on a product of spaces where basic open sets are arbitrary products of open sets (not restricted to finitely many nontrivial factors). "uniform_topology_finer_than_product_and_coarser_than_box"
  • Bubblewrap (bwrap): A Linux sandboxing tool used to isolate and constrain processes. "Inside bwrap, I run the command-line coding agent"
  • Cauchy sequence: A sequence whose elements become arbitrarily close to each other, characterizing completeness in metric spaces. "abs_Cauchy_sequence_converges_R_standard_topology"
  • Classical logic: Logic that allows principles like the law of excluded middle and proof by contradiction. "- This is classical Megalodon (not constructive)"
  • Compactification (context): Here, the process of compressing or pruning an LLM’s session/context to fit within limited memory or token budgets. "Context Compactification"
  • Constructive logic: A logic that avoids non-constructive principles such as general law of excluded middle, emphasizing explicit constructions. "- This is classical Megalodon (not constructive)"
  • Countability axioms: Topological properties related to countable bases or local bases (first/second countability). "countability_axioms_subspace_product"
  • Diaconescu’s proof: A result showing that the axiom of choice implies the law of excluded middle in certain constructive settings. "such as Diaconescu proof of excluded middle"
  • Excluded middle (law of): The logical principle that every proposition is either true or false, with no third option. "- Law of excluded middle (xm) is available"
  • First-order logic (FOF): Logic allowing quantification over elements (but not sets of elements); a standard basis for many ATP translations. "translations to FOF (first-order)"
  • Hammer (in interactive theorem proving): An integration that calls external ATPs from within an ITP to discharge goals automatically. "Megalodon has since 2024 a simple higher-order hammer ``aby''"
  • Hausdorff: A separation axiom (T2) where distinct points have disjoint neighborhoods. "paracompact_Hausdorff_normal"
  • Heine–Borel theorem: In Euclidean spaces, closed and bounded sets are compact. "Heine_Borel_closed_bounded"
  • Higher-order logic: Logic extending first-order by allowing quantification over predicates/functions. "Theory of computation~Higher order logic"
  • Higher-order set theory: Set-theoretic foundations expressed in a higher-order logical framework. "Chad Brown's higher-order set theory system Megalodon"
  • Interactive theorem proving (ITP): Human-in-the-loop formal proof development using proof assistants. "low cost, virtually unknown ITP/library"
  • Lean (proof assistant): A modern interactive theorem prover used for formalizing mathematics. "managed to finish a full Lean proof of my testing paper on Ramsey(3,6)"
  • Least upper bound (LUB): The smallest real number greater than or equal to all elements of a set; key to completeness. "R_lub_exists"
  • Lindelöf: A property where every open cover has a countable subcover (weaker than compactness). "Sorgenfrey_line_Lindelof"
  • Megalodon: A proof assistant/checker for higher-order set theory used in the project. "I use the Megalodon (higher-order set theory) proof checker"
  • Metrizable space: A topological space whose topology comes from some metric. "metrizable_spaces_normal"
  • Metrization theorem (Urysohn’s): A theorem giving conditions under which a topological space is metrizable. "a 2k-line proof of Urysohn's Metrization theorem"
  • Mizar: A long-standing proof assistant with a large mathematical library and LaTeX-like syntax. "our first experiments over a large synthetic Mizar-to-LaTeX corpus"
  • Naproche: A system for checking mathematical texts written in controlled natural language, with proof reconstruction capabilities. "There is so far no proof reconstruction (as e.g. in Naproche)."
  • Net (topology): A generalization of sequences for arbitrary topological spaces, used to define convergence. "continuity_via_nets"
  • Normal space: A T1 space where disjoint closed sets have disjoint open neighborhoods. "Sorgenfrey_plane_not_normal"
  • One-point compactification: Adding a single “point at infinity” to make a non-compact space compact. "one_point_compactification_exists"
  • Order topology: The topology generated by open intervals in a linearly ordered set. "order_topology_basis_is_basis"
  • Paracompact space: A space where every open cover has a locally finite open refinement. "paracompact_Hausdorff_normal"
  • Premise selection: Choosing relevant lemmas/facts to feed to an ATP or prover for a given goal. "premise selection, possibly also some of the well-known translations to FOF"
  • Product topology: The standard topology on a product of spaces generated by basic open cylinders. "product_topology_full_regular_axiom"
  • Proof by contradiction: A reasoning method showing a statement true by deriving a contradiction from its negation. "- Can use proof by contradiction freely"
  • Proof reconstruction: Turning external ATP proofs into internal, checkable proofs inside a proof assistant. "There is so far no proof reconstruction (as e.g. in Naproche)."
  • Ramsey number: In combinatorics, the minimum size guaranteeing certain monochromatic substructures; here, the (3,6) case. "Ramsey(3,6) 4-page paper"
  • Regular space: A T1 space where points and closed sets can be separated by neighborhoods. "regular_countable_basis_normal"
  • Sorgenfrey line: The real line with the lower limit topology; a standard counterexample space. "Sorgenfrey_line_Lindelof"
  • Subbasis (topology): A collection of sets whose finite intersections form a basis for the topology. "product_finite_subbasis_intersection_separator"
  • Subnet: A directed refinement of a net, used to analyze convergence and accumulation. "subnet_converges_to_accumulation"
  • Surreal numbers: A class of numbers including the reals and ordinals, forming a rich ordered field. "surreal numbers (including reals, etc)"
  • T1 space: A separation axiom where singletons are closed (Kolmogorov T1). "locally_m_euclidean_implies_T1"
  • Tietze extension theorem: In normal spaces, continuous real-valued functions on closed sets extend to the whole space. "over 10k-line proof of the Tietze extension theorem"
  • TPTP (TH0) format: A standard problem format for ATP; TH0 denotes typed higher-order logic problems. "export the problems to the TH0 TPTP format"
  • Uniform convergence: Convergence of functions where the speed of convergence does not depend on the point in the domain. "uniform_limit_of_continuous_to_metric_is_continuous"
  • Uniform topology: A topology induced by a uniform structure, capturing uniform notions like Cauchy and completeness. "uniform_topology_finer_than_product_and_coarser_than_box"
  • Urysohn’s lemma: In normal spaces, there exist continuous functions separating disjoint closed sets by values in [0,1]. "This includes a 3k-line proof of Urysohn's lemma"
  • Urysohn metrization theorem: A characterization of normal, second-countable spaces as metrizable. "a 2k-line proof of Urysohn's Metrization theorem"
  • Vampire: A powerful (higher-order and first-order) automated theorem prover. "call e.g. higher-order Vampire."

Open Problems

We found no open problems mentioned in this paper.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 22 tweets with 31042 likes about this paper.