---
title: 'Gödel''s Poetry: Recursive Lean Prover'
url: https://www.emergentmind.com/topics/goedels-poetry
type: topic
---

# Gödel's Poetry: Recursive Lean Prover

Searching arXiv for the primary paper and related theorem-proving systems to ground the article with current citations.
{"query":"arXiv 2512.14252 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" [2512.14252]. It is designed to turn either informal mathematical statements or formal Lean statements into verified Lean proofs by combining specialized language models 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 [2512.14252].

## 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 [2512.14252]. 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 [2512.14252].

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 [2512.14252]. 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 [2512.14252].

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 [2512.14252]. 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 [2512.14252]. 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 [2512.14252].

The pipeline is divided into three broad stages: optional autoformalization, direct proof generation and verification, and recursive decomposition with recursive proving of subgoals [2512.14252]. 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 [2512.14252].

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 [2512.14252]. 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 [2512.14252]. 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 language models can be assigned to different roles via configuration, and the system communicates with external services for proof checking and theorem retrieval [2512.14252]. 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 [2512.14252]. 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** [2512.14252]. 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 [2512.14252].

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 [2512.14252].

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 [2512.14252]. 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 [2512.14252]. 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 [2512.14252].

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 [2512.14252]. 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 [2512.14252]. 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 [2512.14252]. 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 [2512.14252]. The paper gives the following canonical shape:

```lean
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 [2512.14252]. 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 [2512.14252]. 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 [2512.14252]. 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` [2512.14252].

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 [2512.14252]. 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 [2512.14252]. 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 [2512.14252].

## 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 [2512.14252].

| 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 [2512.14252]. 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 [2512.14252]. Configuration is adjustable via an INI file and environment variables of the form `SECTION__OPTION` [2512.14252].

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** [2512.14252]. The tree-structured state management resides in `goedels_poetry/state.py`, AST utilities in `goedels_poetry/parsers/`, and configuration in `goedels_poetry/config/` [2512.14252]. External dependencies include **Kimina Lean Server** for verification, **LeanExplore** for theorem retrieval, and externally supplied LLM endpoints [2512.14252].

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

```bash
pip install goedels-poetry
```

It also provides a CLI under `goedels_poetry` [2512.14252]. The abstract additionally identifies the open-source implementation as `KellyJDavis/goedels-poetry` and notes that it facilitates both adaptation to alternative language models and extension with custom functionality [2512.14252].

## 6. Examples, reported results, and research significance

The paper includes examples intended to illustrate both straightforward and decomposed workflows [2512.14252]. For an even-numbers theorem, the generated formalization is:

```lean
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 [2512.14252]. For a more complex target, the paper gives:

```lean
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 [2512.14252].

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 [2512.14252]. 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** [2512.14252]. 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** [2512.14252]. 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 [2512.14252]. 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 [2512.14252].

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 [2512.14252].

Source: https://www.emergentmind.com/topics/goedels-poetry