Proof Validity Is Not Statement Validity

Part 1 made transformer decode look like a trace.

Part 2 showed why proof boundaries matter: the expensive part is often not one operation, but the proof plumbing around related attention, lookup, range, and state work.

This part is about a different boundary.

Not where the proof should be drawn.

What the proof is allowed to mean.

Here is the whole problem in one small test.

We took an EZKL-style verifier surface and asked two different questions.

First:

does the proof verify?

Second:

does the proof verify as this exact AI receipt: this model, this input, this output, this policy, this verifier domain, this artifact?

Then we tried seven relabeling mutations around the proof.

The proof-only path rejected 1 / 7.

The statement-envelope path rejected 7 / 7.

That is the result to remember.

The cryptography was not the weak part.

The receipt was.

The receipt test

Imagine a contractor gives you an AI receipt.

The dashboard says:

verified.

That feels strong.

But the word “verified” is doing too much work.

Verified which model?

On which input?

With which output?

Under which threshold policy?

Against which verifier?

For which deployment event?

If those answers sit outside the accepted proof statement, someone can keep the proof bytes valid while changing the product story around them.

That is what the receipt test measures.

It does not ask whether the cryptographic verifier can do its narrow job.

It asks whether the accepted object is strong enough to stop relabeling at the application boundary.

The answer in the proof-only path was mostly no.

Only the mutation that touched what the proof verifier actually saw was rejected.

The answer in the statement-envelope path was yes.

All seven relabels changed the accepted statement, so all seven were rejected.

That is why the result is interesting:

This is not a claim that EZKL is broken.

It is the opposite lesson:

proof systems can do correct cryptography and still be integrated behind receipts that are too weak.

Here is the mistake:

the proof verified, therefore the product claim is valid.

That does not follow.

A proof verifier might only answer:

did these proof bytes verify against this relation and public instance?

A product usually wants to say:

this model, on this input, under this policy, produced this output, in this verifier domain.

Those are different statements.

The difference is not philosophy.

It is an engineering boundary.

A human example: the wrong receipt

Imagine a defense supplier running aircraft-maintenance inspections.

An AI model looks at an inspection image and flags a turbine blade as safe, worn, or failed.

The proof verifies this narrow sentence:

a neural network ran and produced status = worn.

That sounds useful.

But it is not the maintenance claim.

The maintenance claim is closer to:

the approved inspection model, version X, ran on this aircraft’s inspection image, captured at this maintenance event, using this preprocessing and threshold policy, and produced status = worn.

Those are not the same sentence.

If the proof does not bind the statement, several bad things can happen without the raw verifier making a mistake:

• the proof was for a test image, but the maintenance record shows a live aircraft;
• the proof was for aircraft A, but attached to aircraft B;
• the proof used an old model, but the report says approved model;
• the proof used a demo threshold, but the operator sees production threshold;
• the proof verified one output, but the record displays another.

The proof is not the maintenance decision.

The proof is a receipt for a computation.

That receipt is useful only if it is attached to the right aircraft, image, model, policy, verifier domain, and output.

This is the same instinct behind software provenance.

SLSA provenance does not merely say a binary exists. It records builder, invocation, materials, and output artifact.

C2PA binds claims, assertions, credentials, and signatures into a manifest.

The analogy for zkML is direct:

a proof without a statement envelope is like a binary without provenance. It may be real, but you do not know which source, build, policy, or event it belongs to.

The local relabeling experiment

We tested this locally with an EZKL-style verifier surface.

The point was not to attack EZKL.

The point was to separate two acceptance predicates:

1. does the raw proof verify?
2. does the proof verify as the exact AI statement the product wants to claim?

The baseline proof verified.

Then we tried seven relabeling mutations around the artifact:

• model id;
• input id;
• output id;
• quantization/config id;
• model artifact hash;
• verifier domain;
• proof public instance.

Then we compared two adapters.

The proof-only adapter asked the narrow question:

does the proof verify?

The statement-envelope adapter asked the product question:

does the proof verify, and is it bound to the exact model, input, output, config, verifier domain, and artifact statement?

The result:

Same result as the receipt test above, now with the artifact shape exposed.

That is the lesson.

Not:

EZKL is broken.

Not:

we tricked a proof system.

The lesson is:

raw proof verification and application-level statement validity are different checks.

The distinction

A raw proof verifier does an important job.

It checks proof bytes against a verifier relation, public inputs, verification key, setup, and implementation.

That job is already hard.

But it is narrower than the sentence a user sees in a product.

The product claim can include:

• model identity;
• input identity;
• output identity;
• quantization policy;
• lookup-table identity;
• verifier domain;
• proof artifact digest;
• deployment event;
• explicit non-claims.

If those fields live outside the accepted statement, they can drift while the raw proof still verifies.

That is the relabeling problem.

The left side is not bad cryptography.

It is a narrow verifier being asked to carry meaning it was never given.

The right side is the fix:

bind the proof and the statement together.

What the envelope adds

The statement envelope does not replace the proof verifier.

It wraps the proof in the facts the application is allowed to rely on.

The envelope says:

• here is the proof;
• here is the proof system and verifier domain;
• here is the model artifact;
• here is the input commitment;
• here is the output commitment;
• here is the numeric policy;
• here are the lookup tables or approximation policies;
• here are the source handles;
• here are the non-claims.

The verifier accepts the package only if both checks pass:

1. the raw proof verifies;
2. the statement around the proof matches the bound commitments and policy.

That is why the envelope rejected 7 / 7 relabels in the local experiment.

The proof stayed the same.

The claimed meaning changed.

The envelope made the change visible.

The practical rule is simple:

do not let the proof travel alone.

What this does not claim

This essay does not claim:

• EZKL core is vulnerable;
• proof systems should verify arbitrary product metadata by default;
• one statement envelope proves a whole model;
• the local experiment is a performance benchmark;
• proof validity is unimportant.

Proof validity is necessary.

It is just not the whole product claim.

The clean claim is:

proof verification is necessary, but it is not the same thing as statement validity.

Next

Part 3 gives the warning.

Part 4 gives the receipt around that object.

If proof artifacts need statement-bound meaning, then the reusable object has to carry both:

proof bytes and the statement they are allowed to mean.

That boundary object needs a name, but the name only helps after the problem is clear.