Claude and Theorem publish a route from fuzz tests to machine-checked software proofs

An October research release reports proofs for 239 entry points across 123 libraries and makes part of the proof collection available for reuse.

Anthropic and formal-verification company Theorem have demonstrated a workflow in which Claude turns existing fuzz tests into mathematical specifications, repairs discovered bugs and produces proofs checked by an independent proof system. Their 22 October research release reports successful proofs for 239 entry points across 123 open-source libraries.

The project works with compiled RISC-V programs and Rocq, a proof assistant whose kernel checks the generated argument. Claude's role is to construct the proof. Acceptance comes from the checker evaluating it against the stated theorem and machine model.

Reusing tests as a specification

The starting material is familiar to many maintainers: a test entry point from Google's OSS-Fuzz ecosystem. A fuzzing engine repeatedly supplies inputs to find crashes. The new workflow instead formulates a statement that the compiled test will not crash for any permitted input, then attempts to prove that statement.

In this experiment, the input bound was 64 MB. The modelled environment was a single-threaded static RISC-V binary on Linux with a fixed memory budget. The researchers also included assertions already present in the tests, allowing some proofs to establish properties beyond memory access—for example, that compressing and decompressing data returns the original input.

The distinction changes how a team can use its existing test investment. A carefully written assertion becomes both a practical regression check and a candidate property for formal analysis. The work of deciding what the program should guarantee therefore remains useful when the verification technique changes.

Bugs found while building the argument

Anthropic reports that the proof attempts discovered errors missed by extensive fuzzing. Some depended on unusually large or precisely structured inputs. Others involved sequences of operations across handles or logic that did not necessarily cause a crash.

When a bug blocked a proof, Claude could propose a patch, regenerate the specification for the changed code and continue. That produces two related outputs: a software change and a proof tied to the resulting executable. The pair is more informative than either artifact alone because reviewers can identify which version the guarantee describes.

The proof collection is large—around 180 million lines of Rocq across the reported effort—but maintainers do not need to read it as ordinary application code. Their review concentrates on the theorem statements, the machine and operating-system semantics, and the proof checker that validates the result.

Shared proofs reduce repeated work

The researchers also explored reuse. Common runtime initialisation and sanitiser code appeared across otherwise different programs, allowing teams to adapt already completed proofs. In a smaller experiment involving 36 tasks, access to shared proofs reduced token consumption by 17%.

That suggests a package-level development model. A widely used dependency could carry proofs for well-defined properties alongside its source and binaries. Applications depending on it could then concentrate on their own calling assumptions and additional behaviour rather than redoing the entire dependency analysis.

Theorem and Anthropic are releasing a subset of the proofs, relevant RISC-V and Linux semantics, and starting materials for other projects. Theorem also provides a Claude skill for adding a project to its pipeline.

The reported guarantees remain attached to the specified entry points and execution model. A multithreaded application on another architecture is a different target. The immediate development opportunity is consequently precise: choose a valuable property, connect it to an actual compiled artifact, and make the checked proof part of that artifact's release record.

Sources

- [LLMs are making formal software verification feasible at a much larger scale](https://www.anthropic.com/research/formal-verification) — Anthropic - [OSS Verify proof collection](https://github.com/theorem-labs/oss-verify-proofs) — Theorem