Gödel's Poetry: Recursive Lean Prover

• Goedels-poetry is a multi-agent theorem-proving system that autoformalizes informal math and recursively decomposes complex theorems into simpler subgoals.
• It employs a supervisor agent to orchestrate a tree-structured search with backtracking and AST-level parsing for reliable Lean 4 proof verification.
• The framework integrates specialized language models for autoformalization, direct proof generation, and verifier-guided proof reconstruction, ensuring robust and reproducible proofs.

Searching arXiv for the primary paper and related theorem-proving systems to ground the article with current citations. {"query":"arXiv (Davis, 16 Dec 2025) Gödel's Poetry Lean4 theorem proving recursive decomposition Goedel-Prover-V2 miniF2F", "max_results": 10} goedels-poetry is the PyPI distribution of a multi-agent Lean 4 theorem-proving system described in "Gödel's Poetry" (Davis, 16 Dec 2025). It is designed to turn either informal mathematical statements or formal Lean statements into verified Lean proofs by combining specialized LLMs with recursive decomposition of difficult theorems into simpler entailing propositions. Rather than treating proof generation as a one-shot decoding problem, it treats proof construction as a tree-structured search procedure coordinated by a supervisor agent, with optional autoformalization, direct proof generation and verification, decomposition of failed proof attempts, recursive proving of extracted subgoals, and final proof reconstruction (Davis, 16 Dec 2025).

1. Scope and problem formulation

Godel’s Poetry addresses a standard failure mode in neural theorem proving: a model may generate a plausible proof sketch, but some subgoals remain too difficult to solve directly (Davis, 16 Dec 2025). In Lean 4, this brittleness is especially consequential because the output must be syntactically valid, type correct, and logically complete. The system is therefore organized around the claim that hard theorems should not be handled solely by direct proof generation; they should also be decomposed into smaller entailing propositions that can themselves be proved recursively (Davis, 16 Dec 2025).

At a high level, the system first attempts to prove the target theorem directly. If that fails, it decomposes the theorem into simpler entailing propositions, proves those recursively, and reconstructs the original proof by substituting verified subproofs back into the proof sketch (Davis, 16 Dec 2025). This makes the proving process cyclic rather than linear. The stated goal is not only benchmark performance, but also a workflow that can start from natural-language mathematics and end with a verified Lean proof (Davis, 16 Dec 2025).

The paper positions this design against several specific difficulties: near-correct proofs that fail on small details, partial proofs that solve only fragments of a theorem, and the informal-to-formal gap between natural-language mathematics and Lean syntax (Davis, 16 Dec 2025). This suggests that the system is intended as an orchestration layer over theorem proving, theorem retrieval, and autoformalization, rather than as a single monolithic prover.

2. Supervisory architecture and proof-tree state

The architecture is built around a supervisor agent implemented with LangGraph, which orchestrates a set of specialized agents (Davis, 16 Dec 2025). Proof state is stored as a tree. Each node represents either a leaf theorem/proof attempt or an internal decomposed theorem with children subgoals. The paper identifies several functions of this tree structure: tracking proof provenance, recursive decomposition, breadth-first recursive solving, backtracking when a decomposition path fails, and final reconstruction of the verified proof (Davis, 16 Dec 2025).

The pipeline is divided into three broad stages: optional autoformalization, direct proof generation and verification, and recursive decomposition with recursive proving of subgoals (Davis, 16 Dec 2025). The supervisor maintains a priority-driven workflow over a tree of pending tasks. The general order is: formalize informal theorem statements; validate the formalization syntactically; validate the formalization semantically; attempt direct proof generation; verify the generated proof; parse successful proofs into ASTs; retrieve relevant theorems for decomposition; decompose failed proofs; and recursively prove subgoals (Davis, 16 Dec 2025).

Two structural features are central. First, the workflow is breadth-first during recursive proof search: all subgoals at one depth are processed before moving deeper (Davis, 16 Dec 2025). Second, the system supports backtracking: if a decomposition path fails, the supervisor can return to a higher ancestor and try a different strategy, provided the correction budget has not been exhausted (Davis, 16 Dec 2025). A plausible implication is that the tree is not merely a bookkeeping device; it is the substrate that makes provenance-preserving search and reconstruction possible.

The architecture is modular. Different LLMs can be assigned to different roles via configuration, and the system communicates with external services for proof checking and theorem retrieval (Davis, 16 Dec 2025). The paper further emphasizes that the framework is model-agnostic and not tied to one provider.

3. Autoformalization and verifier-guided direct proving

For informal theorems, the system uses a three-stage formalization pipeline (Davis, 16 Dec 2025). In Stage 1, a formalizer LLM, by default Goedel-Formalizer-V2, translates the natural-language statement into Lean 4. In Stage 2, the generated Lean code is sent to the Kimina Lean Server for parsing and type checking; if Lean reports syntax or typing errors, the formalization is returned to the formalizer for revision, up to a configured retry limit with default 10 attempts (Davis, 16 Dec 2025). In Stage 3, a separate semantics agent, by default Qwen 3 30B, checks whether the formalization preserves the meaning of the original informal statement, and can veto an inappropriate translation and send the process back to Stage 1 (Davis, 16 Dec 2025).

This separation between syntax validation and semantic validation is one of the system’s defining design choices. Syntactically valid formalizations can still be semantically wrong, so the pipeline is framed as translation plus syntactic and semantic quality control (Davis, 16 Dec 2025).

If the theorem is already formalized, the prover agent attempts a direct Lean proof. The default prover model is Goedel-Prover-V2, used with verifier-guided self-correction (Davis, 16 Dec 2025). The sequence is explicit: the prover generates a complete Lean proof; Kimina checks it; if verification fails, a corrector agent reads the Lean error messages and creates a revised prompt; the model retries; and this repeats subject to configured limits (Davis, 16 Dec 2025). The defaults reported are 2 self-correction attempts per pass and up to 32 passes, corresponding to a Goedel-Prover-V2 style pass@32 evaluation (Davis, 16 Dec 2025).

For verified proofs, the system can request the proof’s AST from Kimina to support later reconstruction if that proof belongs to a larger decomposition tree (Davis, 16 Dec 2025). This links direct proving to the recursive decomposition machinery rather than treating them as separate subsystems.

4. Recursive decomposition, AST parsing, and proof reconstruction

The paper presents recursive decomposition as the main novelty of the system (Davis, 16 Dec 2025). When direct proving fails, Godel’s Poetry switches to a six-step workflow.

First, a search-query agent, by default Qwen 3 30B, generates natural-language descriptions of the kinds of theorems that may help. These descriptions query a vector database, specifically a LeanExplore variant, to retrieve relevant theorems from Mathlib and related libraries (Davis, 16 Dec 2025). This is the RAG step that supports decomposition.

Second, a decomposer agent, by default GPT-5, generates a Lean 4 proof sketch using the retrieved theorems. The sketch contains explicit have statements and sorry placeholders and is required to be logically sound, self-contained, and granular enough that each subgoal is easier than the original theorem (Davis, 16 Dec 2025). The paper gives the following canonical shape:

theorem complex_theorem (n : Nat) : P n := by have lemma1 : Q n := by sorry have lemma2 : Q n → P n := by sorry apply lemma2 exact lemma1

Third, the sketch is validated by the Kimina Lean Server. Lean checks syntactic validity, type checking of the have statements, and whether the overall structure entails the target theorem (Davis, 16 Dec 2025). If validation repeatedly fails, the system backtracks rather than forcing the same decomposition structure.

Fourth, the system uses an extension of the Kimina Lean Server with AST parsing capabilities to inspect Lean code and identify unproven subgoals systematically (Davis, 16 Dec 2025). The added endpoints are POST /api/ast and POST /api/ast_code, with /api/ast_code described as especially important because it accepts arbitrary Lean code, builds a temporary module, runs the AST exporter, and returns structured AST data (Davis, 16 Dec 2025). The parser traverses the proof tree, locates have statements whose proof is sorry, and extracts the subgoal name, type, full theorem statement with context, and metadata derived from the sorry (Davis, 16 Dec 2025).

Fifth, each extracted subgoal becomes a new theorem node at the next depth level. The same proving pipeline is then applied recursively: direct proof generation, decomposition if necessary, and continued search until the subgoal is proved or the maximum recursion depth is reached (Davis, 16 Dec 2025). The default maximum recursion depth is 20.

Sixth, once every subgoal is verified, the system reconstructs the complete proof by replacing each sorry placeholder in the parent sketch with the verified subproof body (Davis, 16 Dec 2025). The paper describes this as recursive substitution that preserves indentation and formatting and yields a final complete proof.

The AST extension is therefore not an auxiliary implementation detail. It is the mechanism that turns decomposition into a programmatic Lean-native operation rather than an ad hoc textual heuristic. The paper explicitly presents this AST-enabled integration with Lean verification as the key technical contribution (Davis, 16 Dec 2025).

5. Specialized models, implementation, and configurability

A core theme of the system is role specialization: different subtasks are assigned to different models because formalization, proof generation, theorem retrieval, semantics checking, and decomposition require different behaviors (Davis, 16 Dec 2025).

Role	Default model/backend	Function
Formalizer	Goedel-Formalizer-V2	Autoformalization
Prover	Goedel-Prover-V2	Direct proof generation
Semantics/Search	Qwen 3 30B	Semantic checking and search-query generation
Decomposer	GPT-5	Theorem decomposition / proof sketching

The framework is model-agnostic at the orchestration level. The paper states that any OpenAI-compatible backend can be used, and that local deployment through Ollama, vLLM, or LM Studio is supported (Davis, 16 Dec 2025). The default configuration file specifies kdavis/goedel-formalizer-v2:32b for the formalizer, kdavis/Goedel-Prover-V2:32b for the prover, qwen3:30b for semantics/search, and gpt-5-2025-08-07 for decomposition (Davis, 16 Dec 2025). Configuration is adjustable via an INI file and environment variables of the form SECTION__OPTION (Davis, 16 Dec 2025).

The implementation is described in concrete software terms. It is written in Python 3.10+, uses LangGraph for orchestration and LangChain for LLM interaction, comprises roughly 5,000 lines of code, and includes about 18 agent types (Davis, 16 Dec 2025). The tree-structured state management resides in goedels_poetry/state.py, AST utilities in goedels_poetry/parsers/, and configuration in goedels_poetry/config/ (Davis, 16 Dec 2025). External dependencies include Kimina Lean Server for verification, LeanExplore for theorem retrieval, and externally supplied LLM endpoints (Davis, 16 Dec 2025).

The system is distributed on PyPI as goedels-poetry, with installation via:

pip install goedels-poetry

It also provides a CLI under goedels_poetry (Davis, 16 Dec 2025). The abstract additionally identifies the open-source implementation as KellyJDavis/goedels-poetry and notes that it facilitates both adaptation to alternative LLMs and extension with custom functionality (Davis, 16 Dec 2025).

6. Examples, reported results, and research significance

The paper includes examples intended to illustrate both straightforward and decomposed workflows (Davis, 16 Dec 2025). For an even-numbers theorem, the generated formalization is:

theorem theorem_b2f45cfb951a : ∀ m n : ℕ, Even m → Even n → Even (m + n) := by sorry

The system then produces a direct proof and Kimina verifies it (Davis, 16 Dec 2025). For a more complex target, the paper gives:

theorem infinitude_of_primes : ∀ n : Nat, ∃ p, p > n ∧ Prime p := by

Its decomposition sketch introduces subgoals such as prod_primes_def, choose_P, prime_divisor_exists, divisor_gt_n, and conclusion, each of which becomes a separate recursive proof obligation (Davis, 16 Dec 2025).

The principal reported benchmark number is a 90.4% miniF2F pass rate without decomposition, stated to match Goedel-Prover-V2’s verifier-guided self-correction result at pass@32 (Davis, 16 Dec 2025). The paper also states that adding recursive decomposition and RAG-guided theorem retrieval significantly improves performance, but that the decomposed version has not yet been fully benchmarked (Davis, 16 Dec 2025). This is an important limitation: the architecture’s central innovation is described as effective, but its aggregate benchmark performance is not yet reported in a finalized form.

For context, the paper mentions prior systems: POETRY improved miniF2F by 5.1%, Hilbert reported 99.2% on miniF2F and 70.0% on PutnamBench, and Goedel-Prover-V2 achieved 84.6% pass@32 with its 8B model and 90.4% pass@32 with the 32B model under verifier-guided self-correction (Davis, 16 Dec 2025). Within that landscape, Godel’s Poetry is characterized less by a single direct-proving metric than by its recursive, structure-aware theorem-decomposition pipeline.

The paper also draws several practical implications. Informal mathematics can be turned into Lean proofs through a formalization-verification loop; hard theorems can be handled recursively; proofs are reconstructible and inspectable because the proof tree preserves provenance; the system is extensible through model swapping and custom agents; and it is usable locally or in distributed setups because verification, retrieval, and model backends are decoupled (Davis, 16 Dec 2025). The authors further suggest the architecture as a platform for research into proof caching, alternative tree search methods, repair of near-correct proofs, RL for decomposition strategies, and human-in-the-loop theorem proving (Davis, 16 Dec 2025).

In that sense, goedels-poetry is best understood as an orchestration framework for Lean 4 proof synthesis in which recursive decomposition, AST-level subgoal extraction, and proof reconstruction are first-class operations rather than afterthoughts. The paper’s central synthesis is that strong direct proving can be combined with structure-aware recursive search in a way that remains verifier-coupled and implementation-ready within Lean 4 (Davis, 16 Dec 2025).