A machine-checked proof has a precise subject. Find the binary, entry point, and specification before translating it into a claim about software safety.
What the project reports
Anthropic’s October 22 research report describes work with Theorem on formal proofs generated with Claude. It reports results for 239 entry points across 123 libraries.
The public repository is a subset: 60 entry points from 25 libraries. It contains artifacts for checking specific claims. Keep the reported total and the public subset separate.
Theorem collaborated on the project. Do not describe its involvement as an independent audit of Anthropic’s results.
The proof applies to a specified execution model
The technical appendix describes compiled RISC-V Linux binaries in a single-threaded model with bounded memory. The project uses Rocq to check proof artifacts.
A checkable proof can establish that its stated property follows under the model’s assumptions. It cannot establish that every function in the library is correct on every architecture.
The specifications and trusted components therefore matter alongside the generated proof. An accurate proof of a narrow property remains a narrow result.
Read the claim as five linked items
I would review a claimed result by recording exactly what each artifact covers. This makes missing evidence visible before a broad security statement reaches a user.
- Identify the binary and its build configuration.
- Name the entrypoint and permitted inputs.
- Read the property stated by the specification.
- Record the execution model and trusted components.
- List behavior outside the claim, including unsupported environments.
For example, proving a selected entrypoint under a single-threaded model leaves a separate question about a multithreaded application using the same library. The application’s behavior needs its own evidence.
Public artifacts make reproduction possible, not automatic
We reviewed the published account and repository scope. MustHave.ai has not built the binaries, run the proof checker, or independently assessed the proof system.
A team evaluating the approach should reproduce one public result before estimating how it fits its own software. Preserve the exact artifact revision and checker result, including dependencies and failed attempts.
Keep operational patching separate from this research. A proof for a selected function does not establish that an installed service has received an unrelated security fix.
Our Serge article discusses verification of generated bug fixes. The PHP security article shows why a discovery claim and a deployment check need different evidence.
Sources
- Anthropic and Theorem research report
- Public proof subset and reproduction artifacts
- Technical appendix and assumptions
What exact property would a proof need to establish before it changes your release decision?
Checked October 25, 2026. Prepared with AI-assisted research and drafting, with claims checked against the linked sources. MustHave.ai has not performed the proposed product tests.
