MechMath: Sorrifier-Driven Formal Decomposition Workflow for Automated Theorem Proving

Introduction to the show: ident: AI Radio. Generated commentary on the latest Artificial Intelligence papers.

Tom: Next we'll be talking about the paper "MechMath: Sorrifier-Driven Formal Decomposition Workflow for Automated Theorem Proving".

Jane: The paper was written by Ruichen Qiu, Yichuan Cao, Junqi Liu, Dakai Guo, Xiao-Shan Gao et al. from Academy of Mathematics and Systems Science, Chinese Academy of Sciences and School of Advanced Interdisciplinary Sciences, University of Chinese Academy of Sciences and School of Mathematical Science, University of Chinese Academy of Sciences.

Tom: Stay tuned as we take you through the paper and discuss its implications.

Title: Tom: Welcome back to the channel, everybody. Today we’re digging into a paper that’s got a name you can’t forget: “Mechanic: Sorrifier-Driven Formal Decomposition Workflow for Automated Theorem Proving.” Jane, I gotta say, the word “Sorrifier” alone made me do a double take.

Jane: It really is a strange word, Tom, but it’s actually perfect once you understand what it does. In the Lean proof assistant, you can write the word “sorry” as a placeholder when you don’t know how to finish a proof yet. The computer accepts it temporarily, but it marks that spot as unfinished. The Sorrifier is a tool that takes a broken proof and strategically replaces the broken parts with those “sorry” placeholders, so the rest of the proof can still be checked.

Tom: So it’s like putting a bookmark in a book you can’t finish reading, instead of throwing the whole book away.

Jane: Exactly. And that’s the core idea of the whole paper. When an AI tries to prove a hard math problem, it often gets most of the way there and then hits one small error. Older systems would just scrap everything and start over, which is wasteful. Mechanic keeps the good parts and only makes you redo the bad parts.

Tom: And the authors are from the Academy of Mathematics and Systems Science in Beijing, plus a bunch of collaborators. They’ve got a big team, and they’re clearly serious about pushing automated theorem proving forward.

Jane: They are. And the implications here are pretty big. We’re not just talking about solving textbook exercises. They tested this on the two thousand twenty-five Putnam competition, which is one of the hardest undergraduate math contests in the world, and they solved eleven out of twelve problems. That’s a level of performance that would have been unthinkable a few years ago.

Tom: Eleven out of twelve? That’s insane. And they did it with a fraction of the time and money that other top systems needed.

Jane: Right. And that efficiency is exactly what we’re going to dig into next. Because it’s not just about whether you can solve the problem, it’s about how fast and how cheaply you can do it.

Tom: Well, I’m hooked. Let’s get into the details of how this workflow actually runs.

Summary: Tom: So Jane, we’ve got the title and the big idea. Now let’s talk about what this system actually does step by step, because the workflow is surprisingly human-like.

Jane: It really is. The system, Mechanic, works in four stages. First, it generates an informal proof sketch, the kind of thing a mathematician would write on a whiteboard. Then it tries to translate that sketch into a formal Lean proof. If the Lean compiler rejects it, the system doesn’t panic. It uses the Sorrifier to find the exact spot where the logic breaks and replaces just that piece with a “sorry” placeholder.

Tom: So instead of starting from zero, it surgically removes the tumor and leaves the healthy tissue intact.

Jane: That’s a good way to put it, Tom. Then it extracts that “sorry” spot as a new, smaller subgoal, proves that subgoal independently, and stitches it back into the main proof. If that subgoal is too hard, it can be split again, creating a tree of subgoals.

Tom: And this is where the efficiency comes from. On the Putnam two thousand twenty-five benchmark, Mechanic took about one hundred fourteen minutes per problem on average and cost about eighteen and a half dollars. Compare that to other systems like Hilbert or Axiom, which sometimes took hours and cost hundreds of dollars.

Jane: Right. And it’s not just about speed. The proofs Mechanic generates are shorter too. They averaged around six hundred fifty-six lines per proof, while other systems often produced proofs that were over a thousand lines long. The proof trees are also shallower, which means less waiting around for one subgoal to finish before the next one can start.

Tom: Shallow and wide beats tall and skinny, got it. But I have to ask, is this just because they used a really good language model, or is the workflow itself doing the heavy lifting?

Jane: That’s the million-dollar question, and they actually tested it. They ran the same pipeline with different language models, from Gemini to Claude to DeepSeek. The stronger models solved all the test problems, while the weaker ones struggled. So the model matters, but the workflow amplifies whatever model you have. Even the weaker models solved problems they couldn’t solve at all without the Mechanic pipeline.

Tom: So it’s like giving a good mechanic a better toolbox. The toolbox doesn’t replace the mechanic, but it makes them way more effective.

Jane: Exactly. And that’s the part that gets me excited, because it means this approach could work with any future model that comes out. You just plug it in and get better results.

Tom: Alright, so we know it works. But what’s actually new here compared to what people were doing before? Let’s talk about that in the next segment.

Improvements: Tom: So Jane, we’ve covered what Mechanic does and how fast it is. But what’s genuinely new here? What did they improve over the state of the art?

Jane: The key improvement is the philosophy of how to handle failure. Older systems like Hilbert or Axiom, when they hit an error, they go back to the informal sketch and re-decompose the whole problem in natural language. That’s wasteful because the formal proof might be ninety percent correct. Mechanic instead decomposes the problem formally, right inside the Lean code itself.

Tom: So they’re not just re-planning in English, they’re actually looking at the broken Lean code and figuring out the smallest piece that needs fixing.

Jane: Precisely. And there’s a subtle technical challenge they had to solve. In Lean, one small error can cause a cascade of fake errors downstream. If you tried to fix all of them at once, you’d delete huge chunks of valid proof. The Sorrifier works around this by targeting the innermost error first, fixing it, recompiling, and then moving to the next one. It’s a very careful, iterative process.

Tom: Like untangling a knot by pulling the loose end instead of cutting the whole rope.

Jane: That’s the idea. And they also added a safety valve. If a subgoal turns out to be impossible to prove, which can happen if the original proof strategy was flawed, the system detects that and goes back to trying to fix the whole proof instead of getting stuck in an infinite loop.

Tom: So it knows when to quit and try a different approach. That’s pretty mature behavior for an AI system.

Jane: It is. And the results speak for themselves. On the IMO two thousand twenty-five problems, which are even harder than Putnam, Mechanic solved four out of five problems they attempted. On the hardest one, Problem one it took about three hundred sixty-three minutes, while the previous best system, Seed, took nine hundred ninety minutes. That’s nearly three times faster.

Tom: Three times faster on the hardest problem. That’s not a small improvement, that’s a game changer.

Jane: And the proofs are cleaner too. The paper shows that Mechanic’s proof trees are wide and shallow, meaning it breaks problems into many small pieces that can be solved in parallel, rather than a few big pieces that have to be solved one after another.

Tom: So it’s not just faster, it’s also more parallelizable. That’s huge for scaling up to even harder problems.

Jane: Exactly. And that’s what we should be thinking about next. Where does this go from here?

Conclusion: Tom: Alright, we’ve covered the title, the workflow, and the improvements. Let’s wrap this up. Jane, what’s the big takeaway from “Mechanic: Sorrifier-Driven Formal Decomposition Workflow for Automated Theorem Proving”?

Jane: The big takeaway, Tom, is that we don’t need to throw away good work just because of a small mistake. Mechanic shows that by being surgical about where errors occur, we can make automated theorem proving dramatically more efficient. It’s a mindset shift from “start over” to “fix the smallest broken piece.”

Tom: And the numbers back it up. Eleven out of twelve Putnam problems, four out of five IMO problems, and at a fraction of the cost and time of previous systems. That’s not incremental progress, that’s a leap.

Jane: It really is. And the fact that the approach works with different underlying language models means it’s not tied to one specific piece of technology. As models get better, Mechanic will get better too.

Tom: So what’s the long-term impact here? I mean, we’re talking about AI that can prove math problems that stump most humans.

Jane: The long-term impact is that we’re getting closer to AI that can do genuine mathematical research. Not just checking proofs, but discovering new ones. The authors even mention that systems like DeepMind’s Aletheia are already moving toward research-level problems. Mechanic is another step in that direction.

Tom: And that could change how we do science, how we verify software, how we teach math. The possibilities are pretty wild.

Jane: They are. But for now, we should say goodbye to this paper. It’s been a fascinating look at how a clever workflow can squeeze so much more out of existing AI models.

Tom: Absolutely. Thanks to everyone who tuned in. Next up, we’ve got a paper on something completely different, so stay tuned.

Jane: See you all next time.