Key Takeaways

  • In a single week, the bounded gap in primes dropped from 246 to 240 by human mathematician Julius Stoman, to 212 by Axiom Math, and to 186 by OpenAI's Astra.
  • Axiom Math treats formal verification in Lean as a performance optimization tool that generates novel algorithms, rather than a safety check.
  • Breaking complex proofs into refactored sub-problems makes partial formal verification practical for real systems instead of waiting for full end-to-end proofs.
  • Ken Ono notes that humans understand only 1 to 2 percent of math, meaning automated systems will churn out useless valid proofs without human taste directing them.
  • Teams evaluating machine-generated proofs and verified code must apply Hong and Ono's Three-Layer Evaluation for AI Mathematical Formalization.

Formal Proofs as an Optimization Engine

Pure mathematics moved at machine speed during a single wild week. The world record for bounded gaps between prime numbers fell three separate times: first Julius Stoman brought the bound down from 246 to 240, then Axiom Math pushed it to 212, and OpenAI's Astra dropped it to 186.

For Carina Hong and Ken Ono of Axiom Math, this race was not an academic stunt. It showed what happens when mathematical reasoning compiles directly into interactive theorem provers like Lean. In traditional software and research, formal verification has a bad reputation. Teams see it as slow, expensive, and academic. Hong argues that view is completely backwards.

“We don't really think of formal verification as kind of like guarding or like capping the downside,” Hong explains. “We think of it in terms of performance and we think of it as optimization. So by having the cost of proof reduced to zero, you can generate new algorithms, you can make new scientific discoveries.”

Engineers often assume verification only helps if you prove 100 percent of a codebase. Hong disputes this all-or-nothing mindset: “People traditionally think of formal verification as something that you get zero credit for if you don't formally prove everything. We think partial verification has a lot of value. By decomposing or refactoring very difficult problems into sub problems.”

Ono points out that critical infrastructure desperately needs this shift: “The world runs on code that people don't understand, many people haven't even read. So software verification, hardware verification as Carina says is kind of the challenge for the future.”

Yet machine-generated proofs create a new hazard: mathematically valid garbage. As Ono says, “The percentage of math that has been understood by mankind that out of all the math that probably exists, it's probably close to like 1 or 2%. Math is we're just always discovering things, but you can prove theorems that nobody cares about or will have no application to the real world. And what's the good in that? So, the human taste and the judgment and the final arbitration for what matters is very much a human thing.”

Hong and Ono's Three-Layer Evaluation for AI Mathematical Formalization

  • Layer 1: Correctness (Formal Proof): Ensure absolute mathematical correctness by compiling and formally verifying the proof in Lean.
  • Layer 2: Code Quality and Formalization Taste: Evaluate the architectural quality of the Lean formalization, including choices of what to keep conditional, class structures, definitions of central mathematical objects, and reusable modularity so the community can build upon it.
  • Layer 3: Mathematical Taste and Arbitrated Importance: Apply human judgment and arbitration to determine whether the theorem or problem being proved actually matters to the scientific community or has practical real-world applications.

When This Works (and When It Doesn't)

This framework works when evaluating whether an automated AI-generated mathematical proof or Lean code module delivers genuine scientific and engineering value rather than valid but useless mathematical slop. It gives technical teams a concrete way to separate mechanical proof-checking from structural quality and domain relevance.

It breaks down if an engineering organization skips Layer 2 or Layer 3 to celebrate a green checkmark in Layer 1. A verified module with poor abstractions creates technical debt that nobody can maintain, even if Lean says the logic compiles.

What to Do With This

Take the most error-prone numerical routine or consensus logic in your codebase this week. Break it down into three self-contained sub-problems. Specify the pre-conditions and post-conditions for the hardest mathematical component, then run an automated prover or Lean formalization on just that module to achieve partial verification without rebuilding your entire stack.