I Can Seal a Wrong Answer

I can seal a wrong answer perfectly, which is not a particularly comforting superpower.

That is the uncomfortable lesson at the center of content-addressed AI results. A hash can tell me that the bytes I am reading are exactly the bytes somebody stored earlier. It cannot tell me whether those bytes came from the computation we said we ran.

The distinction became impossible to ignore while working on delegated inference.

A phone sends a request to a larger machine. A browser hands a long-running job to a peer with more memory. One agent asks another to summarize a document. The remote side returns an answer, perhaps over TLS and perhaps with a signature.

What has actually been established?

TLS tells us which endpoint the connection reached. A signature tells us which key endorsed the response. A content hash tells us the request or answer has not changed. None of those, by itself, proves that the declared model ran over the declared input and produced the returned bytes.

The QVAC verified-inference experiment begins with that smaller, more honest boundary: give the request and result stable identities, then keep integrity and correctness separate.

The job needs a name derived from the job

A delegated request is more than the visible prompt.

The model revision, weight digest, tokenizer, conversation history, generation parameters, prompt template, runtime rules, and anything else that can change the output belong inside the request identity. If a field can alter the result but remains outside the address, two different computations can masquerade as the same job.

Let $R$ be the complete request and $C$ its canonical representation:

$$a_R = H(C(R))$$

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

Canonicalization is load-bearing. Object-key order, Unicode composition, and ignored fields cannot vary from peer to peer. A value without a faithful canonical form should be refused rather than coerced into a convenient but misleading identity.

The resulting address is not a random job ID assigned by a database. Two peers can independently construct the same complete request and derive the same name.

That gives the computation a durable subject before anyone performs it.

The answer can be sealed to that subject

When the provider returns answer bytes $Y$, the consumer stores a record containing the request address, the complete request, the answer, its digest, and the relevant source metadata.

The basic checks are:

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

and

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

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

This already solves real problems. Somebody cannot silently swap the request under the result. A cached answer cannot be edited without detection. A deterministic request that has already produced an accepted result can become a verified lookup instead of another full inference run.

Then comes the sentence that has to remain attached to all of those benefits:

The seal does not prove the answer is correct.

A perfectly intact falsehood is still false

Suppose the provider returns:

Paris is the capital of Germany.

The consumer can hash the sentence, store it, sign it, and verify it a year later. The record may be internally perfect and factually wrong.

A malicious provider can do the same thing without running a model at all. It can invent bytes and return the matching digest. Content addressing catches mutation after publication; it does not force the publisher to perform the computation it names.

The seal establishes this:

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

It does not establish this:

These bytes are the correct result of running the declared model and runtime over the declared request.

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 the phrase verified AI becomes dangerously broad. It may mean transport authentication, signature verification, content integrity, model provenance, deterministic replay, trusted execution, or a mathematical proof of computation.

Those are different layers. A useful system names which one it has reached.

Replay is the plainest correctness check

The most direct way to test a delegated result is to perform the same computation in a trusted environment and compare the output.

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

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

provides strong evidence that the provider produced the expected result—or at least the same result as the trusted implementation.

The QVAC experiment includes that path. It delegates the request, stores the sealed record, then reruns the request locally and compares the resulting hash.

That changes the trust relationship. The provider is not believed merely because it owns a key. Its result can be checked against an independently executed path.

Of course, recomputing every expensive result immediately would erase much of the value of delegation. The interesting policy is selective:

• replay a sample
• replay disputed or high-impact results
• ask multiple independent providers
• accept a previously verified result
• require stronger evidence for irreversible actions
• allow weaker evidence for disposable work

Trust becomes a policy over evidence rather than a permanent property of an endpoint.

Determinism changes the cost curve

A deterministic computation can be named by its complete inputs and implementation identity. Once one result has been checked, others can reuse it if they trust the verification record and can validate its integrity.

The cost changes from repeated inference 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}$$

In the QVAC demo, delegated inference took seconds, verification of a stored record took hundreds of microseconds, and a warmed in-memory table probe took nanoseconds. That last number is a hash-map lookup, not a full proof system. The caveat matters.

The architectural direction still matters too. Work that has already been accepted and checked can move out of the inference lane and into the identity-and-verification lane.

Build systems already use this idea. A compiler does not rebuild an unchanged derivation when the complete input graph points to an output that has already been produced and verified. Deterministic inference can reuse the same pattern when the request identity is complete enough.

A shared table needs attributable claims

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

A network-wide result table is different. Anyone able to write both an answer and its hash can publish a self-consistent false object. The record needs an authenticated statement such as:

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

where $m$ includes the model and execution metadata relevant to the claim.

The signature answers “which key asserted this?” It still does not answer “is the assertion true?”

Policy can then decide which signed statements are acceptable, and stronger evidence can be attached to the same stable request and result objects:

• a trusted execution environment report
• reproducible build and runtime digests
• model-weight and tokenizer digests
• an execution trace
• independent replay receipts
• a verifiable computation proof

Content identity gives all of those artifacts one graph to refer to.

A model name is not enough to replay anything

“Run model-x” sounds precise to a person and is nearly useless as a reproducible request.

Friendly names move. Providers update weights behind endpoints. Tags change. Quantization, tokenizers, chat templates, kernels, stop rules, and sampling defaults all affect output.

A replayable request has to commit to the actual artifacts and rules:

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 human-readable name can remain. It simply cannot be the only identity in the evidence record.

Even with everything pinned, determinism has a boundary. Greedy decoding is easier to reproduce than sampling. Floating-point differences across hardware and kernels can change token choices near a decision boundary. Browser and native paths may not emit identical bytes unless their arithmetic and runtime contracts make that explicit.

The honest claim may be:

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

A stronger exact or proof-producing runtime can expand that boundary. It should not be assumed into existence by the word “deterministic.”

The layers are useful because they stay separate

I now think of delegated computation evidence as a ladder:

1. Request identity — everyone agrees which computation is being discussed.
2. Content integrity — the request and result have not changed.
3. Publisher authentication — a known key made the claim.
4. Execution evidence — the declared runtime and artifacts were used.
5. Correctness evidence — replay, consensus, or proof connects the result to 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 product can stop at any layer depending on risk. The mistake is reaching layer two and describing layer five.

Before you call an answer verified

Take one real delegated request and write down what you can actually show:

• the complete request identity
• the exact result bytes
• the key or service that signed the response
• the runtime and artifact evidence
• the thing that connects the result to the claimed computation

If the last item is blank, do not fill it with a stronger adjective. Call the result intact, attributed, or reproducible—whatever the evidence supports.

Hashes remain essential because every stronger proof needs a stable subject. Without request and result identities, evidence points at mutable endpoint names, database rows, or transport sessions.

The hash gives the answer a durable name and lets me notice when that named object changes.

Then I still have to ask the harder question: What evidence would convince us that this intact answer is actually the result of the computation we meant to run?