Anthropic and Theorem’s new software-verification release gives open-source maintainers something more concrete than an AI assurance: proof files that another program can check. The immediate question for a team shipping software is how to connect that evidence to the particular build, function and operating conditions its users rely on.
Anthropic’s October 22 research account reports proofs for 239 test entry points across 123 libraries. Theorem’s public repository, initially committed that evening, lists a smaller released set: 60 entry points in 25 libraries. Those figures describe different collections. Neither is a count of complete applications certified safe for every use.
TENS analysis: The release is best understood as a new kind of dependency evidence. Its value grows when maintainers can carry a precise guarantee through a software update, rather than attaching a permanent “verified” label to a project name. That requires separating three questions: what was proved, whether it matches the deployed artifact, and what remains to be tested.
Start with the guarantee a user needs
Anthropic describes using Claude to construct proofs about compiled RISC-V code, with Rocq checking the result. The work targets failures reachable through existing fuzz-test entry points under stated input and system assumptions. The company also describes letting the model patch defects during proof attempts and auditing patches against shortcuts that would make the proof easier without preserving intended behavior.
That last distinction deserves attention at the release desk. A successful proof after a code change answers a question about the changed program. Whether the change still delivers the feature people wanted is another review decision. A patch that avoids a failure by refusing useful work could be operationally disappointing even if its narrower mathematical claim holds.
TENS proposes writing a short acceptance statement before requesting a proof. For an illustrative document converter, it might distinguish rejecting malformed input safely, preserving valid content and completing within an acceptable service window. Each requirement would need its own evidence. This example is an editorial proposal, not a claim that the released project verified a document converter or measured those outcomes.
A proof has an address
Theorem’s repository ties its proofs to specific static RISC-V binaries and a formal Linux-process model called LPS. It explicitly excludes a blanket guarantee of library correctness. Wrong results and memory leaks can remain outside the checked properties. The released proofs also do not rule out a run that never ends.
For a service operator, that leaves availability as a separate question. A request that never returns may cause trouble without producing a crash. Treating the absence of one failure mode as evidence against every other failure mode would erase exactly the boundary that makes a formal claim useful.
Our proposed release record would place the proof identifier beside the binary fingerprint, the tested entry point, the environmental assumptions and the unresolved requirements. The maintainer would then mark each deployed use as matching, differing or unknown. A different processor build should receive an explicit explanation of what evidence transfers, rather than inheriting a green indicator from the library’s name.
This record would also improve communication with non-specialists. A product manager does not need to inspect a vast proof file to understand that one parser path has evidence while a different feature remains unassessed. The useful summary is a map of covered behavior, with enough detail for engineers to trace each claim back to its artifact.
Updates need a fresh decision
Theorem offers its OSS Verify program free to qualifying open-source projects. Enrollment requires maintainer participation and build information; existing OSS-Fuzz configurations can be a starting point, although the required static RISC-V build may need adaptation. The program says proofs can take multiple days and that generated findings and patches are not promised human review before delivery.
Those terms put a practical responsibility on the receiving project. A report arriving in a maintainer’s inbox is the beginning of a release decision. The maintainer still needs to decide whether a proposed correction is appropriate, which downstream versions are affected and when users should receive an update.
TENS proposes making proof continuity part of that decision. When a dependency changes, compare the old and new artifact records and identify which guarantees have fresh evidence, which remain applicable with justification and which are pending. A pending proof should be visible as pending. It should neither silently inherit the old result nor be described as a discovered defect.
A useful measure of progress would therefore be the time from a dependency change to a reviewed, deployable release with its guarantees explained. That measure would include human review and integration work as well as automated proving. TENS has not rerun these proofs; this is a proposed evaluation framework derived from the published research, artifacts and enrollment terms. The opportunity is substantial, but the unit of trust should stay specific enough to survive the next update.
Sources: Anthropic Frontier Red Team’s October 22 formal-verification research; Theorem’s OSS Verify proof repository and program documentation.
Featured image: Software code on a computer monitor, used illustratively; not the project’s proof code. Photo: Markus Spiske via Wikimedia Commons. CC0 1.0 Universal Public Domain Dedication. Center-cropped from 5,760 × 3,840 pixels to 16:9 and resized to 2,400 × 1,350 pixels; no generative or content-altering edits.