What the Manifest Hash proves

The hash, in one paragraph

The Verdifax manifest hash is a 64-character lowercase hexadecimal SHA-256 digest. It is computed from a structured record of the entire pipeline run — every input, every kernel execution ID, the hardware attestation measurement, the ZK transcript, the formal-verifier status, the final VFA artifact. Identical inputs always produce identical hashes. Different inputs always produce different hashes (modulo SHA-256 collisions).

What it proves

A valid manifest hash certifies, with cryptographic strength, that:

1. The recorded execution actually happened

The hash binds the input payload, the program identity, the route identifier, the registry record hash, and the runtime measurement into one digest. Producing a different output without changing the inputs is mathematically infeasible.

2. The execution is reproducible

Re-running the same inputs through the same program on the same hardware class yields the same hash, byte-for-byte. Determinism is a primitive of the system, not an aspiration.

3. The runtime was the runtime you claim

Stage 5 of the pipeline incorporates a hardware attestation measurement (TPM2 quote or AMD SEV-SNP report) into the hash. If the operator booted a different kernel, swapped a different model weight file, or ran on a machine that wasn't attested, the resulting hash changes.

4. No party can rewrite history

The hash is sealed. Modifying any field in the recorded manifest invalidates the hash. There is no privileged "edit run #1234" operation, not even for the Verdifax operator.

5. An outsider can verify without trust

Verification requires only the inputs and the hash. The verifier does not need access to the operator's logs, model weights, or runtime. They re-derive the hash and confirm it matches.

What it does NOT prove

This section is here on purpose. Cryptographic claims that overpromise get rightly torn apart in due diligence. We keep this surface narrow.

A manifest hash does not prove:

• That the model's output is correct. A confidently-wrong model produces a confidently-wrong, perfectly-sealed manifest. Verdifax is a notary, not a referee.
• That the model is fair, unbiased, or aligned. Those are evaluation questions; they need their own evidence chain.
• That the training data was licensed, ethical, or representative. Verdifax does not see training data.
• That the values inside the input payload are true. DOG seals the bytes that came in; it has no opinion on whether their content describes reality. Input authenticity is upstream of Verdifax.
• That the user is who they claim to be. Identity is upstream of Verdifax — wire your IAM into the inputs you attest.
• That the same model class will produce the same output tomorrow. A newly-trained version is a different program, with a different registry record hash, producing different manifest hashes.

When a regulator asks "is this AI safe?" the honest answer is "the following claims are now provable; the following remain matters of judgment." Verdifax expands the first list.

Why this scoping matters

Auditors, regulators, and counterparties are skeptical for a reason — the AI industry has under-delivered on accountability claims for years. A proof system that overstates what it proves loses credibility on first contact with adversarial review.

The narrow claim Verdifax does make — runs are sealed and verifiable — is exactly what regulators actually need to satisfy:

• EU AI Act Article 13 (logging and traceability)
• HIPAA 45 CFR § 164.312(b) (audit controls)
• SOX § 404 IT controls (change evidence)
• FedRAMP attestation requirements

The narrowness is the credibility.

Continue

• The nine stages — what each stage contributes to the hash
• Glossary — manifest hash, envelope, attestation, PIA, VFA, ZK