Claude can help produce a proof that particular compiled software avoids specified failures. The result becomes useful evidence when a separate mathematical checker accepts it. That evidence comes with boundaries: the executable, the way it receives input, the property being proved, and the model of the machine all matter.
The public OSS Verify release makes those boundaries unusually concrete. Its repository lists proofs for 60 entry points across 25 libraries as checked on October 25, 2026. An entry point is a particular route through software, not a certificate for every feature of a library. The released proofs also leave open a possibility that matters to anyone waiting for an application to respond: a program can avoid a crash and still run forever.
A damaged image makes the distinction easier to see
Imagine a website that accepts photographs. Its decoder reads a file header, allocates storage, and works through pixel data. A malformed file might supply a length that leads the program outside an allocated buffer.
A test can demonstrate what happens to one file. A fuzzer generates and changes many files, looking for one that exposes a failure. Finding such a file is decisive evidence of a bug. Failing to find one leaves the unexplored cases unresolved.
Theorem’s OSS Verify description proposes a different use for a fuzz target: turn the behavior the test is supposed to enforce into a mathematical statement about the compiled executable. A proof then addresses every input covered by that statement. It does not accomplish this by secretly running every possible photograph through the decoder.
Our upload service is an illustration, not one of the published project results. It helps separate two questions: which examples have survived testing, and what rule has been established for all covered executions?
The author of a proof does not decide whether it passes
The account of how the proofs were made describes automated agents writing Rocq proof scripts against a fixed task. The task identifies the upstream software revision, entry points, compiled builds, and theorem statements. Some released proofs were adapted from Anthropic’s work and checked again against the release’s binaries and model.
That separation is essential. An agent must supply a proof of the required proposition; replacing a difficult claim with a convenient assumption would establish nothing about the program. A persuasive paragraph explaining why code looks safe is also insufficient.
The relevant authority is the Rocq kernel applying the formal rules. The agent can make mistakes, take unproductive approaches, or fail to finish. None of those outcomes becomes a successful proof merely because its author sounds certain. Equally, an unfinished proof is not itself a crashing input or a demonstrated vulnerability.
The checking pipeline binds the proof to the claim
The release’s checking documentation describes several safeguards around the kernel. The pipeline compares each binary with its recorded SHA-256 checksum, builds its mathematical memory image and statements, and compiles the proof files.
It then generates a small wrapper requiring the proof to have the exact type of the intended statement. Finally, it inspects the assumptions the proof depends on and rejects anything outside an allowed list.
These steps answer different questions. The checksum identifies the executable bytes. The wrapper connects the submitted result to the intended theorem. The assumption audit prevents an additional unsupported premise from quietly doing the work of the proof.
The pipeline and the checker remain software with their own trust requirements. Their value is that the acceptance process is explicit and reproducible. Readers can examine what was checked instead of relying on an AI’s description of its own performance.
Input size and memory use are separate conditions
The statement guide explains what the released input driver accepts. Among other rejection cases, it refuses an input file of 64 MiB or more. MiB is a binary unit: 64 MiB is 67,108,864 bytes.
The agreement statements also have memory premises. For a comparison involving AddressSanitizer, the ordinary build must stay within a 2 GiB budget; the corresponding budget for an UndefinedBehaviorSanitizer comparison is 16 GiB. These conditions restrict the inputs the guarantee covers. They do not prove that every input fits within those limits.
Consider a small compressed image that expands into a very large buffer. Being below a file-size limit would not establish that decoding it stays within a memory budget. Before applying a theorem to that upload, a developer would need to establish the theorem’s premises as well as match the executable.
Linux in the proof is a particular model
The released proofs use LPS, a formal model of a Linux process running a static 64-bit RISC-V binary. Its documentation calls the model incomplete and best effort. It describes one thread, does not run signal handlers, and simplifies the filesystem.
Operating-system choices are part of the reasoning. A read may supply only part of the available data, for example, while a memory mapping may choose among permitted addresses. A theorem must cover the choices its statement and model allow. The model’s restrictions and unchecked assumptions still need review before using the result as evidence about a deployed system.
An instruction or system call outside the model is treated as an error for these safety statements. It is not silently assumed safe. Nevertheless, a proved RISC-V executable does not automatically establish the same result for a different ARM or x86 executable, another library revision, or a multithreaded application calling it.
Three promises that deserve different questions
The public results compare ordinary builds with builds containing sanitizer checks, excluding specified failures and relating modeled observable behavior. Agreement is useful, but it does not by itself define the right output for our image decoder. Two builds could agree on the wrong pixel color.
Correctness requires an appropriate specification. Completion requires another property again: termination. The release explicitly states that none of its published proofs establishes a halting statement. A decoder that loops indefinitely can still satisfy a guarantee that does not rule out infinite execution.
For the image-upload example, a claim of proved safety needs four attached answers:
- Executable: which compiled bytes and entry point were checked?
- Inputs: which file-size, memory, and machine-model premises must hold?
- Property: which failures are excluded, and does the statement specify the right decoded output?
- Completion: is termination established, or could the covered program still run forever?
The irrelevant-detail reasoning example shows the same problem at a smaller scale: a checker can establish the claim it receives without deciding whether that claim fully represents the task.
The contribution is substantial within that scope: AI can take on proof-writing work while a separate checker decides whether a precise claim follows. The useful promise is the one written in the theorem, with its conditions attached.
