Anthropic's AI Software Proofs: What's Verified and What Isn't

AI can help produce mathematical proofs that specific software properties hold under defined conditions. Even when a proof checker accepts the argument, that result does not establish that an entire software system is free of bugs.

That distinction is central to Anthropic’s October 22, 2026 research announcement. The company reports that Claude helped produce proofs covering 239 entry points across 123 open-source libraries participating in Google's OSS-Fuzz initiative. Understanding that work means looking closely at the question each proof answers—and where its answer stops applying.

The specification sets the question

A goal such as making an application safe leaves too much unspecified. A specification turns part of that goal into a precise mathematical statement: what must happen, what must never happen, and under which conditions.

A proof supplies the logical argument for that statement. A proof checker examines whether the argument is valid within its formal system. Anthropic's October 22, 2026 research announcement identifies Rocq as the proof checker used for this work.

AI can help construct the argument, but the checker’s acceptance concerns the statement actually submitted. It cannot decide whether the developer chose a sufficiently demanding definition of safety.

This also explains the difference from software testing. An ordinary software test observes what happens in a selected execution. A formal proof can establish a property across all the cases its statement covers, assuming its premises hold. The word “all” belongs to that defined scope.

Tests still have a role in investigating behavior and integration beyond the proven statement. Understanding those remaining questions is part of using the proof responsibly.

One property leaves other questions open

Consider a hypothetical invoice importer. Suppose a proof establishes that its parsing routine never reads beyond a designated input buffer, for files within a specified size limit and under a particular execution model.

That would answer a concrete question about memory access. It would not, by itself, establish that the importer calculates the correct total or restricts each customer to the right account. Those behaviors need their own requirements and evidence.

The example also shows why coverage matters. A proof for a particular fuzz-test entry point can cover all modeled execution paths reachable from that entry point within its stated input limits and assumptions without covering every function in the library. Other entry points and the ways an application uses the library may fall outside the proved property.

A useful verification claim therefore needs to identify both the property and the code it covers.

The execution model sets another boundary

Anthropic reports no-crash proofs for selected fuzz-test entry points under defined conditions. The reported work concerns compiled programs for RISC-V, a processor architecture. The stated conditions include a Linux execution model, one thread of execution, a fixed memory budget, and inputs smaller than 64 MB.

The programs also use static linking, which includes library code in the executable. These restrictions are part of the reported research result, rather than incidental implementation details.

For a team using a different build or runtime, the practical question is whether the proof’s assumptions still hold. Changing the processor architecture or how components are linked can change the program being evaluated. The existing proof does not automatically transfer to that configuration.

Theorem's public OSS Verify repository describes LPS, its formal model of a Linux process, as incomplete and dependent on assumptions. A checker can validate an argument against that model without establishing that it captures every relevant behavior of an actual operating system.

The public release has its own scope

When MiniArticlo inspected the supporting Theorem repository during research on October 27, 2026, its README listed proofs for 61 entry points across 26 libraries. That is a dated observation, not a permanent inventory.

In its October 22, 2026 announcement, Anthropic said it was publishing a subset of the proofs alongside supporting RISC-V and operating-system models. The company-reported study totals and the inspected public collection describe different scopes. The smaller collection should not be treated as independent confirmation of the complete study.

Theorem collaborated with Anthropic on the research. Its repository provides project artifacts for inspection, rather than a separate reproduction by an unrelated evaluator. MiniArticlo has not run the proof checker or independently reproduced the reported results.

For anyone assessing a claim of verified software, the practical questions are specific: Which component and version? Which property? Which execution conditions? What remains assumed or uncovered?

A checked proof answers a precise question. The important next step is making sure that question matches the software decision you need to make.