A proof of inference verifies the computation. Who checks the answer?

The proof is about a computation

A school buys access to a study assistant described as running a particular model. The assistant explains a biology experiment, sounds convincing and supplies a citation. Three questions remain open: did the service use the promised model, does the citation support the explanation, and did the student learn anything? They need different evidence. A cryptographic proof can address a carefully specified version of the first question. It cannot settle all three.

Anthropic’s November 2 research release, FlashProve, is a prototype for proving inference against committed model weights. Its release includes software, a protocol description and Lean formalizations. The company reports experiments using a quantized version of Llama 4 Maverick, with substantial proving overhead compared with ordinary inference. This is intermediate research, rather than an announcement that every Claude response now carries such a proof. Anthropic also distinguishes a faster C++ verifier from a formally connected Lean verifier and identifies remaining audit gaps. Those qualifications matter as much as the headline.

The useful product question is precise: which statement would a successful verification let the school make? In our fictional assistant, a sensible target is that a specified computation using a previously identified model is consistent with the recorded input and output. The assistant might still misunderstand the biology. The proof would make that error attributable to the committed computation instead of leaving open whether an unannounced substitute generated it.

That narrower assurance has value. Schools, customers and evaluators can care about whether the system they evaluated is the system being served. The mistake is to turn computational provenance into a general quality badge. Design the review around the exact statement before designing the badge.

Source: Anthropic: Progress on provable inference for large language models ↗ · The Lean Language Reference: Elaboration and Compilation ↗

A commitment needs a name you can check

Imagine the school has reviewed model release A. The vendor offers release B next month. A proof referring to B does not establish that the assistant used A, even if B is newer or has an impressive evaluation report. Before any individual answer can be checked, someone must connect the human description “the model approved for this course” to the commitment the verifier expects.

A commitment is useful here because it fixes the object against which later claims are checked. Think of it as an identifier with cryptographic obligations attached, rather than a familiar product label. The friendly model name is a separate layer maintained by people and software. A service could accurately prove a computation against a commitment while presenting a misleading explanation of what that commitment represents.

For a product review, ask the vendor to show the mapping. Who issued it? Which model variant does it cover? When did the school approve it? How is a replacement announced? The reviewer does not need to inspect private weights to ask these questions. The point is to avoid treating an arbitrary identifier supplied alongside an answer as evidence that the intended model was used.

Suppose the vendor rotates its infrastructure on Friday. On Monday, the commitment changes. A careful client should not silently accept the new identifier just because the proof checker accepts the associated mathematics. It can display the answer as coming from a model whose approval status has changed, or wait for the administrator to update the approved mapping. This is a policy choice layered above verification.

Keep a record of that choice with its effective dates. An old worksheet might need to be checked against the model approved when the worksheet was generated. Automatically replacing every historical record with today’s friendly model name would erase precisely the distinction the school wanted to preserve. The record can be compact, but it needs to survive ordinary product updates.

Specify what goes into the computation

A student types, “Why did the seedlings grow differently?” The visible sentence is only part of what an assistant may process. The application might add a system instruction, an excerpt from the textbook, a retrieved passage, a conversation summary or a teacher’s lesson plan. A reviewer should ask which of those objects is included in the statement being proved.

Consider a deliberately simple workflow: the application selects one textbook passage, combines it with the student’s question and asks the model for a short explanation. If the proof covers that combined input and the resulting output, it can help establish that the committed model produced the explanation from that input. It does not establish that the selected passage was the best passage, that the textbook was current, or that the application copied the passage faithfully from its claimed source. Those steps need their own evidence.

Now add a calculator. The model requests a percentage change, the application computes it, and the model explains the result. A proof for one model call does not automatically cover the calculator or every other call in the sequence. The product needs a description of the sequence that makes clear which steps carry proofs and how their inputs and outputs connect. Otherwise a proof attached to a final paragraph can invite a broader interpretation than the evidence supports.

This is also where exact representation matters. The text visible on screen might differ from the text submitted to the model because of normalization, hidden formatting or a template. Reviewers should ask how the application preserves the bytes or tokens that the verification process actually uses, and how a human can inspect a meaningful rendering of them. A polished chat transcript is useful for reading; it may be insufficient as the underlying verification record.

For the fictional assistant, write a one-sentence scope statement: “This check covers the identified model computation for the recorded lesson context and reply.” Then list the excluded operations in the technical documentation. That gives teachers a clear boundary without forcing them to learn the protocol before preparing a lesson.

A verifier is part of the system

The proof file does not examine itself. A verifier program receives the statement, the commitment and proof material, then returns a result under a particular protocol. The software interpreting those objects matters. So do its version, its configuration and the assumptions under which the protocol’s security argument holds.

Formal methods can reduce uncertainty here, but their scope must be read carefully. Lean’s language reference describes a small trusted kernel that checks elaborated terms against its type theory; compilation is a distinct step that produces executable programs. A checked mathematical statement and a deployed service are related artifacts, with an engineering path between them. Reviewing that path is part of deciding what evidence the product actually provides.

For the school, ask who controls the verifier. A page that says “verified” because the same server wrote that word offers a different experience from a client running a specified verifier on the actual proof and statement. A school might reasonably delegate verification to a trusted administrator or a separate service, but it should understand the delegation. It should also know whether teachers can export enough material for another implementation to check later.

Next ask about failure. A malformed proof, a missing file, an unsupported verifier version and a valid proof for an unapproved commitment are different states. So is a successful check. Flattening them into a green icon or a red icon makes troubleshooting difficult and can distort what students are told. A missed network download is not evidence that a model answer was forged. A mathematically valid proof for the wrong approved model is not a satisfactory result either.

Ask the vendor to separate the protocol claim from the installation evidence. A description of the mathematics tells a reviewer what a correctly implemented system is intended to guarantee. A build identifier and a reproducible verification procedure help connect that description to the program the school is actually using. Neither artifact replaces the other. Keep them together in the review record so a future update does not leave the school with a strong argument about a program it no longer runs.

It is worth rehearsing an ordinary support incident too. A teacher opens an old reply after the client has updated, and its proof is no longer recognized. The support team should be able to retrieve the relevant verifier version or explain why it has been retired. If a vulnerability leads the vendor to withdraw confidence in an older version, historical results need a clear status rather than a silent rewrite. These are proposed operating requirements for the fictional product, not features we have confirmed in FlashProve.

An appropriate review exercise would deliberately alter one piece of a saved record and observe the verifier’s response in a controlled environment. That is a proposed check, not a report that we performed it. The vendor should document expected outcomes and provide test material so reviewers can distinguish a functioning verification path from a decorative status label.

Correctly generated can still be wrong

Return to the seedlings. The assistant says that one group grew taller because it received more nitrogen. The actual worksheet says only that the groups received different amounts of water. A valid computation proof could coexist with that unsupported explanation. The error is in the answer relative to the evidence, not necessarily in the execution of the claimed model.

The teacher’s review should therefore continue after verification. Open the cited source. Check whether the explanation names a variable present in the experiment. Ask whether an alternative account is possible. If the task requires distinguishing observation from causal interpretation, look for that distinction in the student’s own explanation too. These are ordinary subject-matter checks, and the proof gives no reason to skip them.

This separation becomes even more important when an application adds evaluation scores. Suppose the assistant’s developer says release A did well on a biology benchmark. A proof that release A generated a particular reply does not transfer the benchmark’s average score to that reply. Nor does it establish that the benchmark resembles this lesson or this age group. Computational identity and task performance can reinforce a review, but they do not collapse into one claim.

Give the interface language that reflects this. “Computation check passed” is more informative than “Answer verified,” provided the product explains what computation was checked. Place source information where users can still examine it. If the system offers a confidence indicator, do not derive that indicator solely from the proof result. Otherwise the same mathematically successful check would make both a sound explanation and a confidently stated factual error look equally authoritative.

A teacher can turn this into a useful exercise. Present a fictional reply with a valid computation status and ask students what they would still inspect. Their answer should include the experiment’s evidence and the cited passage. The lesson is that different claims call for different checks, rather than that the machine’s work is beyond question.

Budget for evidence, including its limits

Proof generation and verification consume resources. A purchasing review needs more than a headline tokens-per-second number. Ask which model representation was used, what part of inference the measurement covers, how requests were batched and what hardware was required. Then ask whether the proposed classroom workflow fits those conditions. A throughput result for batched research work does not by itself specify the delay a student will see after submitting one question.

Timing also changes the meaning of a status indicator. If a response appears before its proof is available, the application has a period in which the computation has not yet been checked. It should say so. Decide whether an unverified reply can be used for informal practice, whether a worksheet waits for verification before export, and what happens if checking never completes. Those are product decisions that should be explicit before a school relies on the feature.

Privacy needs a similarly specific conversation. Hiding model weights in a proof is different from protecting a child’s prompt from the service processing it. An exported verification package may include lesson context or student text needed to check the statement. Ask what the package contains, who can obtain it, how long it is retained and whether the school can use a less identifying input in the first place. Do not assume that the phrase “zero knowledge” means every piece of the surrounding application is private.

The review should end with a small set of observable promises. The fictional assistant could promise that an exported record identifies the approved commitment, states the covered computation, retains the material needed for checking and distinguishes pending, failed and successful verification. It should separately describe how sources are assessed and how student data is handled. Each promise can then be examined without borrowing credibility from the others.

A proof of inference is most useful when it closes a particular uncertainty: whether the claimed model computation supports the recorded output. Give that assurance a precise place in the product. Keep the lesson evidence, source review and learner’s understanding visible alongside it. A system with a narrow claim that can be checked is easier to evaluate than one whose most impressive feature is asked to stand behind everything.