Can an AI response prove which model produced it?

An AI service can tell you which model answered a request. A proof of inference tries to let you check that claim. The distinction matters whenever a model name is part of a purchase, an evaluation or an audit: the quality of the prose cannot establish the identity of the computation behind it.

Anthropic and collaborators published FlashProve on 2 November 2026, presenting a public prototype for proving inference against committed weights without disclosing those weights. The announcement describes intermediate research, rather than a finished consumer feature. That is the news. The useful question for builders is more precise: what would an independently checked receipt for one AI response actually mean? The announcement sets out that ambition.

This explainer follows a hypothetical document-review request from model selection to verification. The example is our own, not a FlashProve deployment or a test we performed. We use it to separate a cryptographic statement from the broader claims people might attach to it. The resulting judgement is straightforward: model identity could become checkable, but the receipt must be interpreted as carefully as the answer.

Start with the promise you want to verify

Imagine a company asking a hosted model to review a maintenance report. The customer has approved a particular model revision for the workflow. A response arrives identifying that revision. The customer wants to know whether the approved model actually processed the submitted material, rather than a cheaper substitute or a different configuration that happened to produce plausible text.

Several questions are hiding inside that request. Was the report transmitted intact? Did the service use the authorised model? Were the returned tokens the tokens covered by the check? Did the answer correctly interpret the report? Was private information handled appropriately? Did the surrounding application subsequently send the result to the right person? These questions overlap operationally, but they do not have the same proof obligation.

A proof system becomes useful by narrowing the statement. In the hypothetical workflow, the desired statement might concern an approved model commitment, a specified input and a particular output under a declared inference rule. It should not be a vague certificate saying the service is trustworthy. A narrower statement can be tested for acceptance; a broad assurance slogan cannot tell the customer exactly which failure has been excluded.

This is why a model card and an inference receipt answer different questions. A card describes a model and the evidence available about its behaviour. A receipt concerns a particular computation. Our guide to reading a model card remains relevant because the customer still needs to decide which model should be authorised. A valid receipt does not make that decision for them.

The company in our example therefore starts by writing its requirement in ordinary language: use the approved revision on the submitted report, and let us check the returned result against that revision. It then asks which parts are represented in the formal statement. Any important part left outside needs a separate control, with a named owner and a way to detect failure.

That exercise is valuable before any cryptography is deployed. It reveals whether the actual concern is substitution, factual accuracy, unauthorised access or missing records. If the problem is that a model routinely misreads maintenance terminology, proving that the same model produced the same mistake offers little relief. If the problem is silent substitution during a regulated evaluation, computational provenance is much closer to the requirement.

Follow one request through commitment, proving and checking

The conceptual workflow begins before the request. A provider commits to a set of model weights. Think of the commitment as a fixed reference for subsequent claims, rather than the weights themselves. The customer’s approved-model register must associate the authorised revision with the correct reference. Otherwise, the customer could verify impeccable proofs for a model they never intended to use.

A familiar analogy is ordering a laboratory test. A report identifier helps connect a result to a sample, but an identifier printed on paper does not establish that the sample belonged to the intended patient. A complete process must establish both the identity relationship and the analytical result. The analogy is limited, but it clarifies why a computational certificate cannot replace every surrounding identification procedure.

For the hypothetical maintenance request, the service receives the material that will form the checked input. The provider performs the relevant computation and produces a proof for its claimed result. A verifier then evaluates that proof against the public statement and commitment. The customer does not need to judge the result’s writing style to perform this check. Acceptance follows the verification procedure.

The FlashProve technical report describes this separation into an offline commitment phase and online inference proofs. Its core proposition is to make verification much cheaper than rerunning the large model, while protecting the weights within the cryptographic construction. Those properties concern the proof system’s statement and assumptions, rather than the truth of the generated language.

In a procurement conversation, the most useful artefact would be a concrete specimen receipt. Ask the provider to identify the model reference, input representation, output representation, policy and verifier version. Ask which fields a customer checks locally and which are merely descriptive metadata. If the receipt contains an attractive model label that the verifier never binds to anything, the label remains a claim by the service.

The same scrutiny applies to the report itself. Suppose the application normalises whitespace, removes attachments or truncates a document before inference. The customer needs to know whether the verified input is the original file, an extracted text representation or a different intermediate object. None of these representations is inherently wrong. Trouble arises when the interface implies that the full report was covered while the checked computation concerns only a fragment.

A sensible design would retain enough information to reconstruct that boundary. It might preserve the submitted file, its extraction result and the exact accepted statement, subject to privacy requirements. This is a proposed recordkeeping approach, not a claim about FlashProve’s user interface. The purpose is to make a later dispute answerable without asking everyone to remember what a model-name badge meant months earlier.

The table is a design aid. It does not imply that the prototype implements a complete enterprise approval system. Its point is that the cryptographic core and the operational envelope must agree about what one request means.

Three properties answer three different questions

Completeness asks whether honest execution of the protocol accepts an eligible true claim. Soundness asks whether a cheating party can make a false claim pass. Zero knowledge asks what information the proof reveals beyond the permitted statement. These properties work together, but substituting one for another leads to misleading explanations.

Consider our customer receiving a rejected proof. That rejection is enough to stop reliance on the receipt, but it does not by itself explain the incident. The response might be wrong, the proof file damaged, the configuration mismatched or the integration broken. An operational system needs error handling that preserves the distinction between a failed check and a successful diagnosis of malicious substitution.

Now consider an accepted proof. The customer can rely on the proved relationship to the extent justified by the assumptions and implementation boundary. They cannot infer that every component of the provider’s estate is secure. A provider might correctly perform the checked computation and mishandle the report afterwards. A narrow success should remain narrow when translated into procurement language.

Zero knowledge also needs a named secret. In this case, protecting the provider’s weights is a central objective. That does not automatically make the customer’s prompt secret from the provider, the verifier or every observer. A system can prove a relationship while deliberately revealing its output and other public data. Privacy has to be described through actual information flows, not through the reassuring presence of the word “zero”.

The historical cryptography literature helps explain the separation. Groth’s work on pairing-based non-interactive arguments develops small arguments for arithmetic-circuit statements. The STARK paper by Ben-Sasson and colleagues examines transparent, scalable computational integrity. These are different constructions and research lines, not interchangeable product specifications. Both illustrate that an efficiently checkable argument is an object with defined properties and assumptions.

For readers evaluating a proposal, this history gives a practical habit: ask for the actual protocol, rather than accepting the generic label “a zero-knowledge proof”. The label describes a family of techniques. It does not tell you which operations are represented, how the statement is encoded, what setup is needed or what a particular implementation guarantees.

A useful analogy is a signed package manifest. The manifest can establish who endorsed a set of contents, while leaving open whether those contents do the job. A proof of computation goes beyond endorsement by checking a specified relationship, but it still cannot make the specification wise. Both cases reward careful attention to the exact claim the recipient is being asked to accept.

FlashProve’s release has several assurance boundaries

The public repository identifies FlashProve as a research artifact and says it is not maintained. That status should appear next to any practical recommendation. Public availability allows inspection and experimentation; it does not create a support commitment, a managed service or a safe default for confidential production workloads.

The distinction between implementations is equally important. The project provides a fast C++ verifier and a verifier specified in Lean. Its scope guide says the soundness result concerns the Lean verifier under stated conditions. The C++ verifier and CUDA prover are tested against the protocol rather than themselves receiving the same formal proof. “The verifier is proved” would erase that distinction if used without qualification.

A theorem also has premises. The formal statement distinguishes exact-match acceptance, admissible public setups, the random-oracle model and the cases covered by each theorem. It does not establish an unconditional guarantee for every file a user might hand to an executable. The page also separates single-request statements from batching and distinguishes the abstract verifier from surrounding parsing and execution.

Readers do not have to become proof engineers to understand the consequence. If a deployment changes the acceptance rule, model representation or input handling, it must establish which existing result still applies. Similar-looking code paths do not inherit a theorem through resemblance. The argument depends on the specified object, not on the confidence with which a launch presentation describes it.

The Lean language reference is the appropriate background for understanding Lean as a language and proof environment. Machine checking makes a statement and its derivation inspectable in a way that prose alone is not. It remains necessary to inspect whether that statement matches the desired real-world property and which components connect a running system to it.

There is a productive division of labour here. A cryptographer evaluates assumptions and reduction arguments. A formal-methods specialist examines the statement and trusted components. A systems engineer checks the implementation and integration. A product owner defines the promise made to the customer. None of those perspectives can safely disappear because another part of the stack carries a proof.

For our maintenance-report customer, the actionable outcome is a boundary review. The review should name the verifier actually used, the accepted configuration and any policy differences between the theorem and serving behaviour. It should also identify the person who will revisit the assessment when the provider changes a model. A one-time cryptographic review cannot authorise an unspecified sequence of future revisions.

The approved revision needs a human-readable history

An approved-model register should explain why a commitment was accepted, not merely list a string. In our hypothetical workflow, the maintenance team might approve a revision after reviewing extraction accuracy and its handling of ambiguous terminology. The resulting approval concerns both a model identity and an intended use. A receipt pointing to that identity would then have a concrete decision behind it.

Suppose the provider publishes a replacement trained to produce shorter answers. The new revision could be better for many customers while changing the detail available in this particular report review. The procurement team should be able to recognise the change, test it and decide whether to accept the replacement. A commitment history makes that discussion possible without assuming that “newer” means “approved”.

The history also needs an effective period. A later reviewer should be able to establish which revision was authorised when a disputed request was handled. This is an organisational record, separate from cryptographic soundness, but it gives the soundness result a useful referent. Without it, the organisation may possess strong evidence of an identity and weak evidence that anyone intended to rely on that identity.

The token-rate headline is not a chat-speed promise

Performance is where otherwise careful explanations often go wrong. A statement expressed in tokens per second sounds familiar to anyone buying a model API. Yet the numerator can mean prompt positions processed during prefill, generated response tokens, checked reply positions or a mixture. A proof system’s reported rate therefore needs its workload before it can be compared with an interactive service.

The performance guide reports a particular setup: a public four-bit conversion of Llama 4 Maverick, one H100, 1,024-token prompts and batched work. At 24 requests per batch it reports roughly 111 prefill tokens per second. The guide explicitly says those prompt tokens count, nothing is generated in that main measurement, and startup and commitment are excluded. This is not a measured consumer-chat generation rate.

Batching also changes the user’s wait. Dividing a batch’s processing time by its request count produces a useful amortised cost, but a request does not receive its response after that fraction of the batch has elapsed. It waits for the relevant work to complete. Queueing before the batch and verification afterwards can further separate a throughput statistic from the experience at a user interface.

This distinction is general, rather than peculiar to cryptography. A document-processing job may efficiently handle a large overnight collection while being unsuitable for someone waiting at a terminal. The same hardware can be attractive for one workflow and disappointing for the other. A procurement comparison must begin with the service objective: an audit completed later, an interactive answer now or an assurance record attached asynchronously.

Imagine two hypothetical offers. One returns an answer immediately and provides a proof later. The other withholds the answer until local verification succeeds. The first could suit a retrospective evaluation but would need a rule for what happens if verification fails. The second could offer a clearer reliance boundary but might create a longer initial wait. Neither is automatically superior; they deliver different products.

A serious pilot should therefore measure several clocks. Record when the customer submits the request, when inference finishes, when the proof is available, when verification completes and when the application permits use. Record failures too. A latency distribution that excludes rejected requests can conceal operational pain, while a throughput figure that omits verification can misdescribe the cost of a fully checked service.

These are proposed measurement requirements, not results from a GenAI Brief benchmark. They make the buying decision more concrete. The relevant unit is the completed, accepted workflow under the customer’s load and assurance rule. A proof-generation rate remains useful technical evidence, but it cannot stand in for that entire unit of service.

Weight privacy does not remove operational secrecy work

The public information-disclosure guide is unusually useful because it names what remains visible. Its list includes replies, timing, architecture and sizes, along with other service and file information. It also warns that the list is not proved complete for the released programs. A broad promise that “nothing leaks” would contradict the project’s own qualification.

This matters because confidentiality can fail through the system around a mathematically private object. Diagnostic files, failed responses, counters and operational procedures deserve attention. A deployment cannot repair an accidental disclosure by pointing to a theorem about an idealised prover. The secret has already crossed the boundary the operator intended to protect.

For a prospective adopter, the right first experiment would use public or synthetic material. That is an editorial recommendation based on the research-artifact status and documented limits, rather than a claim that every experiment is unsafe. Public material lets a team exercise its logging, retention and failure paths without confusing a protocol investigation with a commitment to protect valuable private weights.

The cryptographic hash deserves similarly precise language. RFC 7693 specifies BLAKE2. A protocol security argument that models a hash as an ideal random function does not prove that a particular concrete implementation is literally random. The distinction between a mathematical model and an instantiated primitive is part of applied cryptography, not a defect unique to this project.

An enterprise assessment should make that reasoning visible. It should say which assumptions support acceptance and how the organisation will respond to a relevant cryptanalytic or implementation finding. “Cryptographically verified” should lead to a documented dependency register, rather than end the conversation. Long-lived audit records are particularly sensitive to changes in what later reviewers are willing to trust.

Our hypothetical customer also has a different secret: the maintenance report. A model-weight privacy claim does not answer where that report is retained, who can access it or whether a returned proof includes sensitive content. Those questions belong in the data-handling review. Different secrets may require different controls even when they travel through the same service.

A refusal needs a policy of its own

A service can fail to produce an acceptable receipt without delivering a false accepted statement. From the customer’s perspective that still matters: work remains unfinished. The hypothetical maintenance application should distinguish an ordinary timeout, an unavailable proof and an explicit verification failure, while avoiding an automatic fallback that quietly abandons the approved-model requirement. Reliability and soundness answer different questions even when both affect the same button.

Consider an application that retries a failed checked request through an unchecked model and displays the second answer under the original heading. The user might reasonably believe that the visible result passed the promised process. A rigorous proof system has not prevented that interface mistake, because the mistake happened in the product’s interpretation of an absent proof. The application needs a visible status that follows the actual result through retries.

A conservative design might return the report for manual review whenever checked processing is unavailable. Another might permit an unverified draft while clearly preventing its use in the downstream decision. These are illustrative choices, not universal requirements. Their value is to force a product owner to specify the behaviour rather than leave it to an incidental error handler.

Retention introduces another decision. A customer who stores only the natural-language answer may be unable to revisit its computational provenance. A customer who stores all related inputs and proofs could create a larger privacy exposure. The retention policy should identify the minimum evidence needed for the intended dispute and the people authorised to examine it. More records are not automatically better records.

The same applies to human interpretation. An analyst reviewing a receipt should see which claim passed, which verifier made the decision and which scope qualification applies. A green icon with no inspectable statement gives the impression of certainty while hiding the very boundary that makes the feature meaningful. Assurance communication is part of the engineering work because it governs what people do after the check.

For a first pilot, write down a handful of intentionally different cases before running anything: the correct request and result, a changed displayed answer, a mismatched approved revision, an unavailable proof and an unsupported configuration. The aim is not to claim cryptographic validation through a few examples. It is to examine whether the application responds coherently when its assurance assumptions stop holding. Any findings would need to be reported separately from the protocol’s security theorem.

Decide which decisions deserve a receipt

The strongest initial case for proof-carrying inference is a decision that already depends on model identity. An evaluator comparing a fixed revision across time needs confidence that the named revision was served. A purchaser with a specific contractual model requirement has a related need. A researcher investigating behaviour after a release change may want a durable link between the recorded response and the checked computation.

The weaker case is treating proof as an all-purpose badge of quality. If a user’s actual requirement is accurate extraction from a report, the application still needs validation against that task. If the concern is prompt injection, the surrounding agent still needs authority boundaries and careful tool design. Our prompt-injection explainer addresses a different failure class: authentic model execution can still follow malicious instructions.

In the maintenance workflow, a sensible acceptance process has two gates. First, check the computational receipt if model identity is a requirement. Second, evaluate the extracted facts and resulting recommendation using the relevant domain procedure. A failure at either gate blocks the action for a different reason. Keeping both reasons visible avoids converting an assurance feature into an excuse to skip substantive review.

Start an evaluation by writing a short dispute scenario. A supplier says the approved revision produced the recommendation; an investigator later doubts it. What exact evidence would settle the disagreement? If the answer requires an unbound model label, an unavailable commitment or an unverifiable input transformation, the receipt design is incomplete. This exercise often identifies a more useful next task than chasing a faster prover.

Then define the cost boundary. The organisation should know whether it pays for commitment creation, proof generation, transport, storage, verification and re-verification. It should know whether the proposed service covers every request or a selected subset. Selective coverage may be useful, but it cannot establish a universal claim about traffic that never receives a receipt.

Finally, decide who recognises a new model commitment and when old evidence is retained. Model updates are ordinary operations for providers and substantive changes for an assurance workflow. An approval register that silently accepts every new commitment would surrender the very model-selection control the proof was meant to reinforce.

FlashProve makes a sharper conversation possible: which computation can a customer check without rerunning it or obtaining the weights? The deployment decision should stay just as sharp. Approve the statement, identify the remaining trust, and require the application to show exactly when a response has earned the right to be used.