🤖 AI

Goedel-Architect: Streamlining Formal Theorem Proving with Blueprint Generation and Refinement

Goedel-Architect is an agentic framework for Lean 4 theorem proving that utilizes a blueprint generation and refinement strategy to achieve state-of-the-art performance on challenging mathematical benchmarks like MiniF2F, Putnam, and IMO with significantly lower costs than existing pipelines.

Original authors: Jui-Hui Chung, Ziyang Cai, Zihao Li, Qishuo Yin, Rohit Agarwal, Simon Park, Rodrigo Porto, Narutatsu Ri, Ziran Yang, Shange Tang, Xingyu Dang, Hongzhou Lin, Mengdi Wang, Danqi Chen, Chi Jin, Liam H Fo

Published 2026-06-05

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Jui-Hui Chung, Ziyang Cai, Zihao Li, Qishuo Yin, Rohit Agarwal, Simon Park, Rodrigo Porto, Narutatsu Ri, Ziran Yang, Shange Tang, Xingyu Dang, Hongzhou Lin, Mengdi Wang, Danqi Chen, Chi Jin, Liam H Fowl, Sanjeev Arora

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to build a massive, intricate castle out of LEGO bricks. You have a blueprint, but it's not a drawing; it's a list of instructions that says, "To build the tower, you first need a foundation, then a wall, then a window."

The problem is, if you try to build the whole tower in one giant leap, you might get stuck, or you might realize halfway up that the foundation was built wrong.

Goedel-Architect is a new, smart robot team designed to build these mathematical "castles" (formal proofs) in a language called Lean 4. Instead of trying to build the whole thing at once, it uses a strategy called Blueprint Generation and Refinement.

Here is how it works, broken down into simple steps:

1. The Blueprint (The Master Plan)

Before the robot starts building, it draws a Blueprint.

What is it? Think of this as a dependency map. It lists every single small step (called a "lemma") needed to prove the big math problem.
How it works: It draws arrows showing which steps depend on others. For example, "You can't build the roof until the walls are done."
The Twist: Sometimes, if the math problem is really hard, the robot is given a Natural Language Proof. This is like a human mathematician giving the robot a rough sketch or a story about how to solve it. The robot uses this story to draw a better, more accurate blueprint right from the start.

2. The Construction Crew (Parallel Proving)

Once the blueprint is ready, the robot doesn't build one step at a time. It sends out a whole team of specialized builders (a "Lean prover") to work on all the small steps at the same time.

Each builder only looks at their specific step and the steps they are allowed to use (their "dependencies").
They try to build their part. If they succeed, they turn that part of the blueprint Green.
If they fail, they turn it Blue (stuck) or Red (broken).

3. The Fix-It Loop (Refinement)

This is where Goedel-Architect is different from other robots.

The Old Way: Many other AI systems try to solve a problem, get stuck, and then try to break that one stuck piece into smaller pieces over and over again. This is like trying to fix a broken wall by just hammering harder on the same spot. It often leads to a dead end.
The Goedel Way: If a builder gets stuck, the whole team stops and looks at the entire blueprint.
- Diagnosis: The robot asks, "Why did this fail?"
  - Case A (Red): "Oh, this step is actually false!" (The blueprint had a wrong idea). The robot fixes the statement.
  - Case B (Blue): "This step is true, but it's too hard to build right now." The robot breaks this big step into two or three smaller, easier helper steps.
- Revision: The robot rewrites the blueprint with these new, smaller steps and sends the crew out again.
- Efficiency: Crucially, any part of the castle that was already built successfully (Green) stays Green. The robot doesn't throw away good work; it just fixes the broken parts and adds new helper steps.

Why is this a big deal?

The paper claims this approach is a "game changer" for two main reasons:

It's incredibly smart and accurate:
- On a standard test of high school math problems (MiniF2F), it solved 99.2% of them. With a little help from a human-style story (Natural Language), it solved 100%.
- On harder college-level math (PutnamBench), it solved 75.6% on its own, and 88.8% with a little help.
- It even solved problems from very recent, super-hard competitions (like IMO 2025 and Putnam 2025) that no other open-source robot has solved before.
It's incredibly cheap:
- Other top-tier robots that solve these problems often use "black box" models that cost thousands of dollars to run.
- Goedel-Architect uses a cheaper, open-source brain (DeepSeek-V4-Flash).
- The Cost: To solve the entire PutnamBench test, Goedel-Architect cost about $294. The next best open-source competitor cost about $163,000. That's a 500x savings.

The Bottom Line

Goedel-Architect is like a master architect who doesn't just try to hammer a nail; it draws a map, sends out a crew to build in parallel, and when something breaks, it re-draws the whole map to fix the logic, keeping the good parts and only changing what's necessary. It proves that you don't need the most expensive, secret AI to solve the hardest math problems; you just need a smarter way to organize the work.

Technical Summary: Goedel-Architect

Problem Statement

The paper addresses the challenge of formal theorem proving in Lean 4, specifically aiming to bridge the gap between high-performance proprietary systems and accessible, open-source pipelines. While frontier AI systems have demonstrated significant mathematical capabilities (e.g., IMO gold medals, solving open Erdős problems), the verification of these proofs requires rigorous formalization. Existing open-weight solutions often struggle with difficult benchmarks like PutnamBench (scoring <15%), while high-performing systems rely on unreleased models or expensive proprietary APIs (costing thousands of dollars per benchmark run). The core difficulty lies in efficiently decomposing complex theorems into provable lemmas without getting trapped in recursive dead-ends or incurring prohibitive computational costs.

Methodology

Goedel-Architect is an agentic framework centered on blueprint generation and refinement. Unlike approaches that rely on recursive top-down decomposition or single-shot proof generation, this system operates on a global dependency graph.

1. Blueprint Generation

The process begins by generating a blueprint, defined as a dependency graph of formally stated definitions and lemmas that build up to the target theorem.

Structure: The target theorem is the unique sink of the graph. Each node represents a definition or lemma, and edges represent declared dependencies (i.e., which lemmas a proof is allowed to rely on).
Input: The formal statement of the theorem always seeds the generation. Optionally, for difficult problems, a natural-language proof (generated by a stronger model or provided as a solution) can act as a structural guide.
Validation: The generator iterates against the Lean compiler to ensure the emitted file parses, all nodes are well-typed, and the graph is acyclic and connected.

2. Parallel Theorem Proving

Once the initial blueprint ( $G_0$ ) is generated, the system dispatches each lemma node to a tool-equipped Lean prover in parallel.

Context: The prover for a specific lemma sees only the lemma itself and its declared dependencies (available as facts), not the entire graph.
Tools: The prover utilizes the Lean compiler for type-checking and a Mathlib retrieval service for lemma lookup.
Diagnosis: If a lemma fails, the prover returns a structured diagnosis. This includes:
- Negation: If the prover finds a counterexample, it registers a proof of the negated statement.
- Gap Analysis: If the lemma is unproven but believed true, the prover identifies where the proof chain breaks.

3. Blueprint Refinement

If any lemmas remain unproven, a refinement model rewrites the global blueprint ( $G_{k+1}$ ) based on the failure signals.

Strategies: Refinement includes decomposing hard lemmas into helper lemmas, rewiring dependencies to grant access to necessary results, or altering/dropping statements that the prover has proven false.
Preservation: Successfully proven lemmas from the previous iteration are preserved (green nodes) with their signatures intact, ensuring that computational effort is not discarded.
Iteration: The revised blueprint is re-proven in parallel. This loop continues until all nodes are solved or the iteration budget is exhausted.

Key Contributions

Blueprint-Centric Architecture: The paper introduces a global dependency-graph approach that contrasts with recursive decomposition. This allows parallel proof attempts to share context and enables refinement to act on the entire strategy simultaneously rather than locally.
Open-Weight State-of-the-Art: The system achieves state-of-the-art performance using the open-weight DeepSeek-V4-Flash (284B-A13B) backbone, avoiding the need for unreleased models or proprietary frontiers.
Cost Efficiency: The pipeline is significantly more cost-effective than comparable high-performing systems. The paper reports a per-problem cost of ~$0.44, which is up to 500× less than other open-source pipelines and orders of magnitude cheaper than proprietary alternatives.
Natural-Language Seeding: The framework demonstrates that optional natural-language proofs can serve as effective structural scaffolds for the initial blueprint, particularly for problems with non-local structures (e.g., cyclic sums, divisibility chains), helping to anchor the strategy for the refinement loop.

Experimental Results

The system was evaluated on five benchmarks: MiniF2F-test, PutnamBench, IMO 2025, Putnam 2025, and USAMO 2026.

MiniF2F-test: Achieved 99.2% pass@1 (242/244 problems) without natural-language guidance. With optional natural-language seeding, it solved all 244 problems (100%), setting a new record for open-weight systems.
PutnamBench: Achieved 75.6% pass@1 (508/672 problems), outperforming the Hilbert pipeline (70.0% at pass@1840) and AxProverBase (54.7% at pass@1). With natural-language guidance (pass@4), the solve rate increased to 88.8% (597/672).
IMO 2025: Solved 4/6 problems.
Putnam 2025: Solved 11/12 problems.
USAMO 2026: Solved 3/6 problems (a contamination-free benchmark as the problems post-date model training cutoffs).

Cost Analysis: On PutnamBench, Goedel-Architect solved the full set of 672 problems for $294 in API costs. In contrast, the next best open pipeline (Hilbert) reportedly spent ~ $163k–$ 170k for a single run, highlighting a massive efficiency gap.

Significance and Claims

The authors claim that Goedel-Architect establishes a new Pareto frontier for formal theorem proving. It demonstrates that high-level performance (rivaling massive proprietary systems like AlphaProof or systems using Claude Opus 4.5) can be achieved with a highly efficient, open-weight backbone and a novel pipeline design.

The paper emphasizes that the combination of the global dependency graph (allowing holistic refinement) and open-weight models (DeepSeek-V4-Flash) is the key driver of this success. The system effectively closes the gap between academic accessibility and frontier performance, making high-level formal proving feasible at a fraction of the previous cost. The authors note that while natural-language guidance significantly boosts performance on the hardest problems, the core pipeline remains robust and effective without it on standard benchmarks.