A proof can get a computer's approval without earning your trust. Trail of Bits has demonstrated that with Lean, the software behind two of this month's biggest AI math announcements, the practical response is to check what the approval depends on before you rely on it. A second check helps only if it doesn't inherit the same blind spot. This is the Augur Dispatch for Thursday, September 10th, 2026. A quick disclosure before we begin. Portions of the Augur Dispatch Podcast are generated using artificial intelligence. The written dispatch contains the full source trail and verification notes. The important qualification comes first. Trailabits did not break Lean's core logical checker. Its demonstration used a feature that trusts the results of compiled code, and a bug, let that code, disagree with Lean's own mathematical definition. That's a narrower finding than saying formal verification is broken. It's also a useful warning for anyone buying a system on the strength of the words machine check. Picture developer preparing a result for review. The status says passed. The manager asks whether it's verified, and the developer says, yes. Nobody has lied, but they may be using the same word for very different levels of assurance. Trail of bits says the issue affects stable lean releases through 4.33.1. The memory safety fix merged roughly three hours after filing, and the remaining mismatch was fixed five days after the record. The patch is incorporated in 4.34.0, release candidate 1. Updating matters. It doesn't replace checking the proof's assumptions. Lean's own guidance separates ordinary checking from the stronger protection needed for potentially malicious proofs, including unreviewed AI submissions. It recommends inspecting assumptions and, for high-risk cases, comparing the intended statement and using external checkers in a protected workflow. If a proof relies on a native computation that another checker can't validate, accepting that computation again doesn't make the second check independent. The team has to address that dependency. For an engineering leader, adopt the inventory work now. Find results whose acceptance depends on lean, record the version and assumptions, and recheck affected work on a build containing both fixes before calling it verified. The operating advantage would come from making review repeatable. A team that knows exactly what it accepted can investigate a newly disclosed bug without reopening every project from memory. Auger's suggested pilot is one consequential proof workflow owned by the engineering lead. Record today's review time and unresolved assumptions. Then add statement comparison and a genuinely independent check where supported. Review the results in a week. Expand only if the intended statement and acceptable assumptions survive both checks with a manageable review burden. Stop reliance on any result the team cannot validate. OpenAI's claim solution to the Navier-Stokes problem needs another distinction. These equations describe fluid motion, and the company says its internal system resolved a long-standing question about whether a particular kind of smooth flow can break down. It published a mathematical write-up and a lean formalization. The supplied reporting had not established mathematical acceptance as of September 9th. This episode does not resolve that question, and the lean exploit is not evidence that OpenAI used the trick. There is also a dispute about how the work began. NYU mathematician Tristan Buckmaster alleges OpenAI learned about his progress before it was public. OpenAI says it heard rumors that prompted its effort, but did not see the researcher's work before publication. It also says it cannot rule out de-identified product usage data helping improve its models. That is the company's response, not an independent finding about what happened. Mathematical correctness and research provenance require different evidence. A proof file cannot settle who knew what, and a dispute about priority does not by itself show that a mathematical argument is wrong. For buyers, this remains a watch item. Don't turn an unresolved research announcement into a capability guarantee in a contract. There is a more constructive example of checking in AI2's account of Goodfire's work on Olmo. Goodfire traced part of a safety regression back to individual training examples and predicted behavioral changes before a full training run. The training data contained pairs of answers labeled preferred and rejected. Some preferred answers encouraged behavior the researchers wanted the model to refuse. AI2 publishes those examples, along with intermediate models and training recipes. That let Goodfire investigate specific causes and test targeted changes, rather than guess from the finished model alone. Give the engineer who owns a model update that starts answering requests it used to refuse. With the training record available, there's a concrete place to investigate. Without it, the engineer may spend days changing prompts around a problem introduced elsewhere. These are the company's reported results without outside replication established in this brief. They still give procurement teams a useful question about access to the training process, beyond whether the finished model's weights are downloadable. A downloadable model is helpful, it isn't necessarily a maintenance manual. Mistral's energy sector migration makes the same point through older software. The starting reservoir simulator had no test suite and no central documentation. Mistral says its first sprint migrated 40,000 of 300,000 lines from Fortran 77 into C. Crucially, the team built a comparison hardness before migrating. It captured outputs from the old program, including intermediate values selected by reservoir engineers, and compared them with the new implementation. Matching the old program doesn't prove the underlying physics is correct. It provides evidence that the translation preserved the behavior being compared. That is a useful, bounded claim. Picture the reservoir engineer reviewing an unfamiliar replacement. A large count of translated lines doesn't answer whether an important pressure calculation still agrees. A comparison at the relevant checkpoint gives that conversation somewhere to start. Mistral also reports that human supervised workflows worked better for this project than fully autonomous migration. For a leader pricing a modernization contract, fund the comparison setup and specialist review explicitly. The source figures remain Mistral's account, not independently replicated results. OpenAI's commercial offering is moving to. Astra reached Snowflake's Cortex AI and private preview yesterday. It is already available directly through OpenAI, including its API, so Snowflake's preview status should not be confused with the model's overall availability. OpenAI says it is training a more capable internal model. Government testing reportedly requested no changes to Astra, but that doesn't establish the absence of every outside constraint. Augur's procurement judgment is to keep routing switchable and avoid commitments that assume today's model will remain the best available option. Today's Augur call puts a 35% probability on OpenAI making a model it identifies as newer than GPT-6 Astra, generally available through its API by December 31st, 2026. A qualifying public announcement or model page makes it a hit. No such listing by the deadline makes it a miss. These dated calls make Auger's judgments testable. The website tracks them so readers can judge the record, not just the confidence of the wording. Adopt the verification inventory now. Pilot stronger checking on one consequential workflow. Watch the unresolved math claims without treating them as settled science. The written daily dispatch contains the full source trail, the verification limits, and the items Augur is watching next. That is the Augur Dispatch for Thursday, September tenth, twenty twenty six. Thank you for listening.