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. Scaffold today. the hardware-attestation step currently emits a scaffold value rather than a real TEE quote; it activates when the orchestrator is deployed on confidential-compute silicon. The hash still binds whatever the hardware-attestation step reports (real measurement or scaffold value), and the audit bundle's scaffold field flags which one applies. See /concepts/scaffold-gaps/ for the activation procedure.

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.

Outcome-dependent manifest semantics

The meaning and scope of the manifest hash depend on the run's outcome state:

OK runs

For OK runs, the manifest hash seals the full pipeline state: envelope + DTL transport + DKEC kernel outputs (EPA, EFA, six execution IDs) + AER + ZKSP (transcript, hardware attestation, leakage, formal verifier) + Sealing + ledger + registry + DLA + the AllowToken decision fields. Note: ZKSP includes steps that emit scaffold values today (zero-knowledge proof, hardware attestation, formal verifier), every audit bundle flags these explicitly; see /concepts/scaffold-gaps/.

The canonical preimage includes all 18 manifest fields. This is what you verify when you call verdifax.verify(manifest_hash, ...).

pepg_deny runs

For pepg_deny (policy rejection), the manifest does not contain full pipeline state, only the policy-evaluation portion. The sealed artifact is the DenyReceipt, not the manifest. The DenyReceipt seals: envelope_id, policy_hash, evaluation_hash, fired_rule_id, decision_reason_code, mcd_finding_hash (if MCD matched), deny_clock.

The manifest hash shown in the run summary is still valid but seals only the partial state. The canonical artifact is the DenyReceipt hash, not the manifest hash.

ccv_halt runs

For ccv_halt (per-run budget breach), the pipeline stopped mid-flight. The sealed artifact is the CCVHaltReceipt, which seals: envelope_id, allow_token_hash, budget_hash, constraint_type, budget_limit, consumed_at_halt, partial_execution_hash (the state of work completed before halt), halt_clock.

The partial_execution_hash seals the work completed up to the halt point. The canonical artifact is the CCVHaltReceipt hash, not the manifest hash.

macc_halt runs

For macc_halt (cumulative budget breach), no execution occurred. The sealed artifact is the MACCHaltReceipt, which seals: envelope_id, tenant_id, allow_token_hash, budget_hash, constraint_type, budget_limit, cumulative_at_halt, per_run_consumption, window_start, halt_clock.

The canonical artifact is the MACCHaltReceipt hash, not the manifest hash.

In summary: For OK runs, the manifest hash is the canonical seal. For non-OK runs, the receipt hash is the canonical seal. The audit PDF and run summary show the appropriate hash based on outcome_kind.

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