A Hash Can Prove an Answer Was Not Changed. It Cannot Prove the Answer Was Right.

I can seal a wrong answer perfectly.

That is the uncomfortable thing about content addressing. Hashes are very good at proving that bytes have not changed. They do not know whether the bytes were produced by the right computation.

The distinction matters whenever computation crosses a trust boundary.

A phone delegates inference to a server. An agent asks another agent to summarize a document. A sensor sends a model input to a nearby peer. A browser hands a long-running job to a machine with more memory. The remote side returns an answer.

What exactly has been proven?

Usually, not much. TLS proves which endpoint the client reached. A signature can prove which key endorsed the response. Neither proves that the claimed model ran, that the request was interpreted correctly, or that the returned bytes are the deterministic result of that computation.

The QVAC verified-inference experiment starts with a smaller property: give the request and answer stable identities, then separate integrity from correctness instead of blurring them together.

Name the request before sending it

A delegated request is more than a prompt.

It includes the model artifact, the model checksum, the conversation history, generation parameters, and anything else that can change the result. If two peers are supposed to reproduce the same computation, those fields have to be inside the identity.

Let $R$ be the complete request and $C$ its canonical representation. The request address is:

a_R = H(C(R))

The canonicalization step is load-bearing. Key order, Unicode composition, and ignored fields cannot be allowed to change differently on different peers. Values without a faithful canonical form should be refused.

flowchart LR
    P[Prompt] --> R[Complete request]
    M[Model name + weights checksum] --> R
    G[Generation parameters] --> R
    H[Conversation history] --> R
    R --> C[Canonicalize]
    C --> A[Request address]

The address is not an arbitrary job ID. It is derived from the job itself.

That gives the system a useful property: two peers can independently construct the same request and derive the same name without coordinating through a database.

Seal the answer to the request

When the provider returns an answer $Y$ , the consumer stores a record containing:

the request address
the complete request
the answer bytes
a hash of the answer
source metadata
the time the record was created

The simplest integrity checks are:

H(C(R)) \stackrel{?}{=} a_R

and

H(Y) \stackrel{?}{=} h_Y

If someone changes the request under the record, the first check fails. If someone changes one byte of the answer, the second check fails.

sequenceDiagram
    participant C as Consumer
    participant P as Provider
    participant T as Local table

    C->>C: derive request address
    C->>T: lookup address
    alt cache miss
        C->>P: delegate complete request
        P-->>C: answer bytes
        C->>C: hash answer and seal record
        C->>T: store sealed record
    else cache hit
        T-->>C: sealed record
        C->>C: re-derive request and answer hashes
    end

That is already useful. A cached answer cannot be silently modified. A request cannot be swapped under an unrelated response. A repeated deterministic request can become a table lookup rather than another inference run.

But none of this proves correctness.

Integrity is not correctness

Suppose the provider returns:

Paris is the capital of Germany.

The consumer can hash that sentence, store it, re-hash it later, and verify that it has not changed.

The record is internally consistent and factually wrong.

A malicious provider can do the same thing more deliberately. It can compute nothing, invent an answer, and return a perfect hash of the invented bytes.

The seal proves this:

These are the same bytes the consumer previously accepted for this request address.

It does not prove this:

These bytes are the correct result of executing the declared model over the declared request.

That second claim needs another mechanism.

flowchart TD
    R[Request identity] --> I[Integrity]
    Y[Answer bytes] --> I
    I --> S[Stable sealed record]

    R --> C{Correctness evidence}
    Y --> C
    C -->|recompute| V[Reproduced result]
    C -->|attest| A[Trusted execution claim]
    C -->|prove| P[Verifiable computation proof]

    S -. alone is insufficient .-> X[No correctness guarantee]

This is where a lot of “verifiable AI” language becomes slippery. The word verified may refer to transport authentication, signature verification, content integrity, model provenance, deterministic replay, or mathematical proof of execution. Those are different claims.

A useful system should name which one it provides.

Recompute when it is cheap enough

The most direct correctness check is replay.

The consumer or an independent auditor runs the same request against the same pinned model and compares the result bytes.

If generation is deterministic and the runtime is bit-reproducible, then:

Y_{\text{delegated}} = Y_{\text{recomputed}}

is strong evidence that the provider performed the expected computation—or at least produced the same result as a trusted implementation.

The QVAC experiment includes this path. It delegates an answer, stores the sealed record, then runs the same request locally and compares the resulting hash.

That changes the provider relationship. The provider is no longer believed merely because it holds a key. It is checked.

Recomputation is not free, of course. If every consumer recomputes every expensive answer immediately, delegation has accomplished very little.

The interesting network design is selective verification:

recompute a sample
recompute disputed results
ask multiple independent providers
reuse a previous verified result
require stronger proofs for high-impact operations
accept weaker evidence for low-risk, disposable work

Trust becomes a policy over evidence rather than a binary property of the endpoint.

Determinism changes the economics

A deterministic computation can be named by its complete input and implementation identity.

Once one result has been verified, other consumers can reuse it if they trust the verification record and can validate its integrity.

The cost shape changes from repeated compute to resolve-and-check:

\operatorname{cost}(R) = \begin{cases} C_{\text{compute}} + C_{\text{seal}}, & \text{first accepted result} \\ C_{\text{lookup}} + C_{\text{verify}}, & \text{reused result} \end{cases}

The QVAC demo measured delegated inference in seconds, record verification from disk in hundreds of microseconds, and a warmed in-memory table probe in nanoseconds. The nanosecond number is a hash-map lookup, not a full proof system. That caveat is important. It still shows the architectural direction: proven work can move out of the inference lane and into the identity lane.

This is the same intuition behind content-addressed build systems. A compiler does not rebuild an unchanged derivation because the system already has an output bound to the complete input graph.

Inference can use the same idea when the request is complete enough and the runtime is reproducible enough.

Shared records need signatures

A local table has a simple trust model: the process that wrote the record trusts its own storage.

A network-wide table is different.

Anyone who can write both the answer and its hash can create a self-consistent false record. Content addressing catches mutation after publication; it does not identify the publisher or prevent a new false object from being introduced.

A shared record needs an authenticated statement such as:

\sigma = \operatorname{Sign}_{k_{\text{provider}}} \left(a_R \parallel h_Y \parallel m\right)

where $m$ carries the relevant model and execution metadata.

The signature answers “which key made this claim?” It still does not prove the claim is true. It makes the claim attributable and lets policy decide which attestations are acceptable.

For stronger guarantees, the signed statement can reference:

a trusted execution environment report
a reproducible build identifier
a model-weight digest
a runtime digest
a proof trace
independent recomputation receipts

Content identity gives those artifacts a stable graph to attach to.

The model identity cannot be a friendly name

“Run model-x” is not a reproducible request.

Model names are mutable labels. Repositories can move tags. Providers can update weights behind an endpoint. Quantization, tokenizer versions, templates, runtime flags, and sampling parameters can change output.

A request that aims to be reproducible should commit to the actual artifacts:

flowchart LR
    N[Friendly model name] --> D[Resolved revision]
    D --> W[Weights digest]
    D --> T[Tokenizer digest]
    D --> Q[Quantization / format]
    D --> R[Runtime + generation rules]
    W --> A[Complete request address]
    T --> A
    Q --> A
    R --> A

The friendly name remains useful for humans. It should not be the only thing inside the proof record.

Determinism has a boundary too

Greedy decoding with a fixed model and fixed runtime is much easier to reproduce than sampled generation.

Even then, cross-hardware floating-point differences can change token choices near a decision boundary. Different kernels can accumulate in different orders. Library versions can alter tokenization or stop conditions. Browser and native runtimes may not emit identical bytes.

The honest claim may therefore be narrower:

This request reproduced byte-for-byte on these pinned builds and hardware classes.

A stronger substrate—exact arithmetic, deterministic kernels, or a proof-producing runtime—can expand that boundary. It should not be assumed into existence.

Keep the claims separate

The stack I find useful is layered:

Request identity — everyone agrees which computation is being discussed.
Content integrity — the request and answer have not changed.
Publisher authentication — a known key made the claim.
Execution evidence — the claimed runtime and model were used.
Correctness evidence — replay, consensus, or proof establishes that the result follows from the request.

flowchart BT
    I[Request identity] --> C[Content integrity]
    C --> S[Signed attribution]
    S --> E[Execution evidence]
    E --> P[Correctness proof or replay]

A system can stop at any layer, depending on the risk. The mistake is reaching layer two and describing layer five.

Hashes are still enormously valuable. Without stable request and answer identities, every stronger proof has to refer to mutable names, transport sessions, or database rows. Content addressing gives the evidence a durable subject.

It just does not make the evidence true by itself.

A hash can prove an answer was not changed.

Correctness begins with the next question: what would have to be checked to prove this answer came from the computation we named?