The astronauts would never

Four years old. A flight simulator. The wrong program. Before Apollo 8, Margaret Hamilton's daughter Lauren was playing with the command module simulator at MIT's Instrumentation Lab when she launched P01, a pre-launch routine, while the simulated spacecraft was in flight, and crashed it. Hamilton, whose MIT obituary ran Wednesday, proposed a software guard. She was overruled: the astronauts were highly trained and would never make that mistake. On Apollo 8, Jim Lovell made that mistake, and the navigation data vanished.

AI mathematics is making the same bet in a new place, and this week someone checked. On Tuesday three researchers at King's College London and Cambridge posted a paper comparing OpenAI's separately announced proof that Navier–Stokes solutions blow up in finite time against the Lean code that was supposed to certify it. Where Lemma 8.6 in the prose controls the output with m+4 derivatives of the input, the Lean estimate it cites needs m+5. The pressure-flux bound in equation (10.19) differs in both its statement and its argument. The authors even ran their reading past OpenAI's own GPT-6, which, a figure caption notes, "shares our concern."

This column argued Wednesday that the Lean proofs largely settle whether OpenAI's results are true. That was too generous by exactly one step. A Lean kernel certifies the Lean. Whether the paper — the thing mathematicians will read, cite and build on — says the same thing is a separate question, and the certificate is silent on it. The authors put it flatly:

The prose is also where the errors are surfacing. On Wednesday OpenAI withdrew three manuscripts after a sign error broke a cancellation argument in one paper and the construction two others depended on, and it revised 14 more with proof repairs. By its own count, 300 of 719 top-line results now have a formalization, about 42 percent. For the rest, the prose is all there is. For the formalized ones, the prose is still what a person reads — and in the Navier–Stokes case, the bridge between the two was built by a model.

Hamilton's career was built on that seam. The Apollo guidance computer did what it was told; the failure lived where a person handed it an instruction it had no reason to doubt. Her answer wasn't better astronauts. It was software that stopped assuming the input would be right, an early case of what we now call defensive programming. MIT's Olivier de Weck describes a career dedicated to preventing errors and what she called "handling the unknown."

The math equivalent isn't exotic. Every formalized result should ship with its seam exposed: which Lean theorem certifies which numbered claim, and a plain note wherever the two differ — m+5 where the paper says m+4. That's a table, not a treatise, and people who will never read a line of Lean can check it. It puts human scrutiny on the one step the kernel can't see.

A Lean kernel certifies the Lean.

The strongest objection is that this is pedantry. One derivative in a lemma is the kind of slip referees catch in human papers every week, the top-line Lean theorem may still be exactly right, and no human refereeing process could have checked hundreds of papers in a week. All true. The kernel is more trustworthy than any referee, and a faithfully stated formal theorem settles its own truth. But the astronauts' training was real too. It was also the reason the guard got refused. A certificate that reads as covering the prose is the dangerous kind, because it switches off the scrutiny that catches a sign error.

Lovell was among the best-trained operators alive, and he still selected P01. Nobody should expect better from a translator they haven't checked. Guard the handoff.