You cannot personally verify most of what your AI tools produce. Neither can mathematicians, which is why they built something to do it for them. The Lean theorem prover, created by Leo de Moura at Microsoft in 2013 and now open-source, checks every step of a proof against the fundamental rules of logic. Its mathematical library, mathlib, holds nearly 300,000 theorems and 2.5 million lines of verified code, contributed by over 700 people. Nothing enters unless it passes the checker.

That separation between generating an answer and proving it correct is the part most operations leaders are missing. This post looks at what a verification layer actually costs, what it buys you, and where it belongs in your quality and manufacturing workflows.

Your AI Produces an Answer. Nobody Can Verify It.

An LLM can draft a deviation report, a CAPA summary, or a process risk assessment in seconds. Checking it properly takes your quality lead an hour. Scale that across a plant and the verification cost eats the entire productivity gain. In a regulated environment, output nobody has signed off on is output you cannot use.

Mathematicians hit this wall before manufacturing did. Thomas Hales, writing in an October 2026 guest post on Terence Tao’s blog, describes the problem precisely: AI now reads a paper and emits a formal proof, far faster than any human referee can read it. Their answer was not more reviewers.

It was a machine that checks the work, exhaustively, against the rules of logic. Trust moved from the author to the checker. That shift is the one worth copying.

What Lean and mathlib Actually Are

A proof assistant is software that checks an argument step by step against the foundations of logic. Not a spot check, not a review, every step. The software either accepts the proof or rejects it, and there is no middle state where something is probably fine.

Lean itself is only the checker. What makes it useful is mathlib, the mathematical library started in 2017 by Mario Carneiro and Johannes Hölzl, who took pieces of Lean’s core library and split them into something separate. Jeremy Avigad, now director of Carnegie Mellon’s NSF institute ICARM, was the first user of Lean and ran a seminar on it back in 2015.

The reusable library effect: cite Cauchy-Schwarz instead of reproving it

Every theorem in mathlib is a verified building block. If your new proof needs the Cauchy-Schwarz inequality, you cite it from the library. You do not reprove it, and the checker does not re-examine it, because it was already machine-checked when it went in.

That is the compounding part. Over 100,000 definitions and nearly 300,000 theorems sit there as settled ground, each one usable by anyone building something new. Verification cost drops as the library grows, which is the opposite of how most quality systems behave.

Why Lean won out among Coq/Rocq, Isabelle, HOL Light, Mizar and Metamath

Lean was not the first. Automath, HOL Light, Isabelle, Coq (renamed Rocq last year), Metamath and Mizar all came before it, and Freek Wiedijk’s book “The Seventeen Provers of the World” compares them by proving the irrationality of the square root of two in each. Technically, several are comparable.

Lean won on adoption, not elegance. De Moura persuaded Microsoft to open-source it, which removed the licensing question entirely. Then 700-plus contributors built mathlib into 2.5 million lines of code, and that library became the reason to pick Lean over anything else. The tool with the deepest verified knowledge base wins, and the gap widens every month.

Autoformalization: The Economics Just Changed

Formal verification used to be absurdly expensive. The formal proof of the Kepler conjecture on sphere packings in three dimensions took roughly 20 human work-years and ran to about 500,000 lines of proof script. Every line was transcribed by hand from a paper proof. That is a career, spent not on new mathematics but on proving that existing mathematics holds up.

Autoformalization collapsed that cost. AI reads the paper, a PDF or a TeX file, and emits the formal proof code directly. The transcription labour that made verification unaffordable is largely gone, and the results show it. The four-colour theorem, Feit-Thompson, sphere eversion, sphere packing in 8 and 24 dimensions, Navier-Stokes forced blowup, and Fermat’s Last Theorem have all been formalized. The last three were finished in 2026 alone.

The pattern that transfers: a fast generator paired with a strict checker

Notice what did not change. The checker stayed exactly as strict as it was. AI got faster at producing candidate proofs, and the verification layer kept rejecting anything that did not hold. The speedup came entirely from the generation side, which is the only side where speed is safe.

This is the architecture worth copying. You do not make your AI more trustworthy by prompting it harder or by adding a second model to review the first. You pair a fast, fallible generator with a deterministic checker that has no opinion and no bad days. The generator can be wrong constantly, as long as wrong output never gets through.

In an operations context, the checker is rarely a theorem prover. It is your spec limits, your batch records, your material certifications, your historical process data. An AI-drafted deviation report can be automatically tested against the actual sensor readings and the actual procedure text before a human ever sees it. Build that test once and it runs on every output forever, which is precisely the economics that made formalization viable at scale.

Where Machine-Checking Wins, and Where It Still Leaves You Exposed

A machine-checked proof tells you one thing with total certainty: the argument holds. It tells you nothing about whether the statement at the top of that argument is the one you cared about. That distinction is where most of the residual risk lives, in mathematics and in your plant.

The specification gap: correct answer, wrong question

Lean will reject a flawed step without mercy. It will also happily verify a theorem about the wrong object, as long as the logic is internally sound. Someone still has to write the formal statement, and that translation from human intent to formal specification is a human judgement call.

This is exactly the joint that snaps in operations deployments. You specify a model to flag out-of-tolerance parts, and it does, correctly, against a tolerance definition that quietly excludes the measurement condition you actually worry about. The output passes every check you built. The check was aimed at the wrong target.

There is a small irony worth noting. Hales’ own post carries an editorial note from Terence Tao: it “was initially written in a different file format and converted using AI.” The conversion was almost certainly fine. Nobody formally verified it either.

What this costs to build and maintain in a real operation

The cost is not the checker. The cost is the specification work and the library you check against. Mathematics got lucky here, because mathlib’s 700-plus contributors built a shared foundation over nearly a decade, and any new result can cite what is already there rather than reprove it.

You do not have that library. You have to build it: formal definitions of your tolerances, your release criteria, your deviation categories, maintained by people who understand both the process and the formalism. Expect that to be a standing role, not a project.

Verification moves risk from “did the AI get it right” to “did we ask the right question.” That is a much better place for your risk to sit. It is not an empty one.

Building a Verifier Layer Into Your Own AI Workflows

The architecture that matters here is not the model. It is the split between the thing that generates and the thing that decides whether the output is acceptable. Hales points out that mathematicians never had to trust the AI doing the formalization, because the checker sits underneath it and answers yes or no. You need the same arrangement, and you almost certainly do not have it.

Start by writing down acceptance criteria that a machine can evaluate. A batch record summary must reconcile against the MES data it claims to describe. A CAPA draft must reference an existing deviation ID and a real root cause code. A supplier risk score must fall within bounds derived from the actual incoming inspection history. These are checks a script can run in milliseconds, and they catch the failures that actually hurt you.

A three-question audit of where your AI output goes unchecked today

Run this over every AI-assisted process you have running. First: what decision does this output feed, and who signs it? Second: if the output were wrong in a plausible way, what would catch it, and when? Third: could a rule engine, a database query, or a schema validation catch that same error automatically?

Anywhere the answer to the third question is yes, build the check and route output through it before a human sees it. Anywhere the answer is no, you have found the real gap. That is where to invest, not in a better prompt. Freek Wiedijk’s book compared seventeen different provers by having each prove the irrationality of the square root of two, a deliberately small, well-defined target. Start the same way.

The payoff is not speed. It is that verified output survives contact with an auditor, a regulator, or a customer complaint investigation. Unverified AI drafting stays stuck in the sandbox forever, because nobody will put their name on it. A verifier layer is what moves it into production.

Source: terrytao.wordpress.com