Most AI output lands on your desk as a confident assertion you have no practical way to check. The optimal packing of 11 squares went the other way. The proof shipped as Lean code in a public repository, with an ElevenSquare.lean entry point, a dedicated verification folder, a PROVENANCE.md file, CI workflows, and credit to a contributor who ran the thing on an HPC cluster. Nobody has to trust the model. A compiler either accepts the proof or it does not.

That distinction matters more to you than the geometry does. Below, we break down what mechanical verification actually looks like in an industrial setting, which of your AI use cases can be held to that standard today, which cannot, and what changes in your error rates and audit time when you stop accepting output on faith.

Your AI Vendor Says ‘Trust the Output.’ This Repo Says ‘Check It.’

Every AI pilot in a regulated plant dies in the same meeting. Someone from quality asks how the output was produced and whether it can be reproduced. The vendor talks about benchmarks, human review, and confidence scores. None of that is evidence. It is a promise, and promises do not survive an audit.

The 11 Squares project took the opposite route. Its optimality proof was integrated into a public Lean 4 repository on 6 October 2026, alongside build files, CI workflows, and a lake manifest pinning every dependency. Anyone can clone it and run the check themselves. Agreement is not required.

That is the part worth copying. The geometry is a curiosity. The pattern, where the answer arrives with a machine-checkable artifact attached, is what your AI systems currently lack.

What the 11 Squares Formalization Actually Contains

The proof artifacts: Lean source, verification and simplification pipelines

Strip away the headline and what is left is a fairly ordinary software project. Two Lean modules sit at the root, ElevenSquare.lean and Sqpack.lean, each backed by a directory of the same name. A lakefile.lean defines the build and lake-manifest.json pins the dependencies. If you have ever reviewed a build system in your own plant software, none of this will look exotic.

The interesting part is the separation of concerns. There is a verification/ directory and a separate simplification/ directory, which tells you the raw proof and the cleaned-up proof were treated as distinct stages. There is also docs/, a scripts/ folder, and an integrations/wand125 directory. Four commits total, the last one dated 6 October 2026.

The paper trail: PROVENANCE.md, MISSING.md and an AGENTS.md file

The markdown files are where this gets useful as a template. PROVENANCE.md records where the work came from. MISSING.md records what is not there yet, which is the single most unusual document in the repository. Almost no AI deliverable you receive comes with a written list of its own gaps.

ASSEMBLY.md, SIMPLIFICATION_HANDOFF.md and PC_RESUME.md round out the handoff documentation, and ACKNOWLEDGEMENTS.md credits Julian-JJ for enabling proof execution on an HPC cluster. Compute was a real constraint, and someone wrote down who solved it.

Then there is AGENTS.md, the conventional file for instructing AI coding agents. Its presence signals agents were part of the workflow. What the excerpt does not tell us is which models were used, how much of the Lean source they wrote, or where humans intervened. That matters, and it is worth being precise about the limit of what we can see here. The verification claim does not depend on those answers, which is exactly the point.

Why a Machine-Checked Proof Beats a Confident Answer

There are two ways to decide whether AI output is correct. One of them scales. The other is what most organisations are doing right now.

Human spot-checks don’t scale with AI output volume

Spot-checking works when a model produces twelve answers a week. It collapses at twelve thousand. You end up sampling, and sampling means you are explicitly choosing not to look at most of what the system produces.

The deeper problem is that a reviewer’s approval is not evidence. It is an opinion, recorded by someone who was probably reviewing the fortieth item that morning. When a customer complaint investigation asks why a particular decision was made eight months ago, “our process engineer reviewed it” is the answer that ends careers. It cannot be reproduced, and it cannot be re-run on demand.

Deterministic acceptance criteria turn review into infrastructure

Flip the model and the AI becomes a candidate generator rather than an authority. It proposes; something mechanical accepts or rejects. In the 11 Squares work, the checker is the Lean 4 compiler, wired into GitHub Actions workflows so the verdict is produced by the build rather than by a person’s judgement. Pass or fail, every time, on the same input.

That certainty has a price, and the project is honest about it. The acknowledgements credit Julian-JJ for enabling proof execution on an HPC cluster, which tells you verification was expensive enough to need serious hardware. Compute is the cheaper half of that trade. Reviewer hours cost more, scale worse, and produce nothing an auditor can replay. Buy the determinism.

Where the Verify-Don’t-Trust Pattern Transfers to Manufacturing, and Where It Doesn’t

The test is simple. Can you write down, in advance, what would make the answer wrong? If yes, a checker can run that condition on every output, every time, without a human in the room. If no, you do not have a verification problem. You have a judgement problem, and dressing it up in automation makes it worse.

Checkable problems: layouts, tolerances, spec conformance, rule-based CAPA

Plenty of plant work has a checkable condition hiding in it already. Nesting and cutting layouts have a hard constraint: no overlap, inside the sheet boundary, within kerf allowance. That is geometry, and geometry is exactly what the 11 Squares work mechanised. An AI can propose the layout. A deterministic checker confirms it before anything touches material.

The same logic covers tolerance stack-ups (the computed worst case either sits inside the limit or it does not), spec conformance against a documented characteristic, line balancing against takt and station capacity, and CAPA logic where the SOP already states which action follows which failure mode. Treat configuration changes the same way the repository does, with CI workflows and a pinned manifest. Every proposed change runs the regression suite before it ships.

Unverifiable problems where human judgement stays in the loop

Then there is the other half. Supplier risk narratives, root-cause storytelling, decisions about whether a deviation is systemic or a one-off, prioritising which of eleven open NCRs actually threatens the next audit. No compiler accepts or rejects those. There is no correctness criterion to write down, so there is nothing to check against.

Use AI there anyway, but change what you expect from it. It drafts, summarises, surfaces patterns, and a qualified person owns the conclusion and signs it. The failure mode worth avoiding is applying the machine-checked proof standard where it cannot apply, declaring the output verified because it came out of a controlled pipeline, and quietly removing the reviewer who was the only real control.

The Three Questions to Put to Every AI Vendor Before Your 2027 Budget Closes

Budget season is when this gets decided. Once a contract is signed, you inherit whatever verification story the vendor has, and in most cases that story is a dashboard. Ask three questions before that happens.

A procurement checklist: check, provenance, continuous verification

• What is the independent check on each output? Not a confidence score produced by the same system. A separate mechanism that can return a hard fail, running on criteria you define.
• What provenance record travels with each result? The 11 Squares repo ships a PROVENANCE.md and an ACKNOWLEDGEMENTS.md. Your vendor should be able to tell you which model version, which inputs, and which checker version produced a given answer, months later.
• Does verification run automatically on every change? That repo keeps a .github/workflows directory for exactly this reason. Verification that only runs when someone remembers is not verification.

If a vendor cannot answer all three in a single meeting, the gap is not documentation. They have not built it, and you will be the one paying for human review to cover the difference.

The ROI argument sits in that review cost. Most AI business cases assume the model’s output goes straight into the process. In practice a qualified person reads it first, and that review eats the savings you approved the project for. Automated checking is the only thing that removes the bottleneck without removing the control.

Pick one process this quarter where correctness can be written as a rule. Dimensional conformance against a drawing tolerance. Label content against a regulatory field list. Shift schedules against a working time agreement. Define the fail condition first, in writing, before any model touches it.

Then build the checker before you buy the generator. A machine-checked answer you can reproduce in six months is worth more than a cleverer answer nobody can defend.

Source: github.com