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 the pipeline's artifacts: the envelope and payload hash, the transport, every kernel execution ID, the AER, the hardware attestation measurement, the ZK transcript, the formal-verifier status, the final VFA artifact, and the policy, budget, governance and actor fields. It does not cover the bundle's descriptive sections: the authorization chain, the causal graph and real-world effects, the request substance, and the system provenance. It also seals two per-run values that every /execute call mints fresh, the admission clock and the public-log leaf nonce, and it binds the run's own public-log entry. The same manifest fields always produce the same hash, and a change to any field produces a different hash (modulo SHA-256 collisions). Because the clock and the nonce are new on every call, two separate submissions of identical caller inputs produce different manifest hashes, by design: each run is its own record and its own entry on the public log.

What it proves

A manifest hash that recomputes from its sealed record shows, with cryptographic strength, the following:

1. The sealed manifest fields have not changed since they were sealed

The hash binds the payload hash, the program identity, the route identifier, the registry record hash, and the runtime measurement field into one digest. Altering any manifest field while keeping the same hash is computationally infeasible. The hash does not by itself show that an execution took place; it shows that the manifest fields are the ones that were sealed. It says nothing about the descriptive sections it does not cover. For an anchored run, the public Sigstore Rekor entry shows when the log recorded the run's leaf.

2. The record recomputes, and the pipeline replays deterministically

Recomputing the hash from a run's sealed manifest fields yields the recorded value, byte-for-byte, and any altered field yields a different one; GET /runs/{id}/verify performs this check. The pipeline's computation is deterministic: replaying the same inputs under a pinned clock and nonce, with the public-log anchoring stage held fixed, reproduces the same manifest hash byte-for-byte, and POST /execute/verify-determinism runs exactly that check. Determinism is a primitive of the system, not an aspiration.

What this does not mean: a production run cannot be re-run to its own hash. Each /execute call mints its own clock and nonce, and a production record's hash also binds its own unique public-log entry, so a later submission of the same inputs is a separate record with its own hash. A production record is verified by recomputing its seals from its recorded fields, not by re-running it.

3. On a hardware-attested deployment, which hardware the run used

This applies only to deployments with a SEV-SNP agent configured. The hosted Verdifax service runs without one today, so its runs carry no hardware evidence and show nothing about the runtime. The hardware measurement enters the hash through the execution record. With a SEV-SNP agent configured, the record's hardware field is the SHA-256 of a verified AMD SEV-SNP report taken before the record was built, and that field is sealed into the manifest. The report's launch measurement covers the attested guest's firmware, not the orchestrator binary, so that the orchestrator ran inside that guest remains the operator's statement. Without an agent, the field holds the published no-hardware value and the bundle's scaffold field says so. The Stage 5 hardware_attestation_hash is a legacy placeholder. See /concepts/scaffold-gaps/.

4. A rewrite of what the record anchors no longer matches the public log

Modifying any field in the recorded manifest without also changing the recorded hash makes recomputation fail. For an anchored run, the public log fixes what was logged, and what that covers depends on when the record was sealed. Records sealed from run 238 (2026-10-16, 17:06 UTC) on carry a second entry, the complete-record anchor, over a digest of every section of the record; from run 239 on, deleting it fails verification, so a rewrite of any section no longer matches the public log. Since verifier 0.12.0, a public-log entry counts only if it is signed with a published Verdifax log-signing key and the timestamp the log signs for it verifies, so a rewritten record that anyone else logs as a new entry fails. Verdifax holds that key. From run 240 on, each record seals a 600-second anchoring window, so a later re-log, even by Verdifax, fails or must carry a new sealed date; earlier records show their authenticated anchoring time but cannot fail on it. On records sealed before run 238, the entry binds the run's identity and, under leaf v5 (runs 236 and 237), its 33 pre-anchor values, which include the attested decision, the AIVP governance result, the payload hash, the actor and the scaffold flags; their descriptive sections (outcome summary, request substance, authorization and approval chain, real-world effects, system provenance) are sealed by hashes inside the bundle but are not bound to the public log, so a party able to rewrite the whole bundle can change them and recompute those hashes without detection. Records sealed before leaf v5 have no 33-value table; their leaf binds the run's identity values. The API has no "edit run #1234" operation, not even for the Verdifax operator. Someone with direct access to the database could still alter a stored record; the verifier detects that only for what the record anchors.

5. An outsider can verify without trust

Verification works from the sealed record, not from the caller's original inputs, and needs no access to the operator's logs, model weights, or runtime. The open-source verifier, verdifax-verify, reads the run's audit bundle and, offline, recomputes every section hash, the bundle hash and, for anchored runs, the public-log leaves from the bundle's own fields; confirms every section is bound to the same manifest hash; and checks the Sigstore Rekor inclusion proof against a public key embedded in the binary. Re-deriving the manifest hash itself takes the full stored manifest, which the orchestrator holds; GET /runs/{id}/verify performs that check server-side for authenticated callers.

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. Since 2026-10-02 it also seals the execution record's own fields (formula, input, control and program hashes, hardware field and attestation flag, proof). Note: ZKSP includes steps that emit scaffold values today (the transcript, the zero-knowledge proof binding and its formal verifier status, the leakage bundle, and the legacy hardware placeholder), every audit bundle flags these explicitly; see /concepts/scaffold-gaps/.

The canonical preimage includes every sealed manifest field. This is the preimage GET /runs/{id}/verify re-derives server-side from the stored manifest fields.

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 at the post-DKEC check (stage 3.5), after the kernels had executed. The consumption CCV compares with the budget is caller-declared (request_substance.cost.total_tokens); a run that reports none counts as zero. 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), the pipeline halted at stage 3.6, after the DKEC kernels and the CCV check had run and before AER; no later stage ran. 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 record-keeper, 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 model actually produced the submitted output. When your code calls the model and hands Verdifax the prompt and response, the seal covers what you submitted, not what the model emitted; those are the same only if your code is honest. Routing the output through the AIVP-T4 review stage adds an independent second-model check, and the hardware-attested execution path closes the gap further, but a plain attest call proves submission, not provenance.
• That caller-declared context is true. Model name, model version, actor role, and decision fields in the attested-context block are recorded verbatim from the caller and sealed as claims made at sealing time, not as facts Verdifax checked.
• 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 the kind of evidence organizations can use for their own record-keeping and audit-control duties under:

• EU AI Act Articles 12, 19 and 26(6) (record-keeping and log retention, duties of the provider and deployer of a high-risk AI system)
• HIPAA 45 CFR § 164.312(b) (audit controls, duties of the covered entity or business associate)
• SOX § 404 (internal control over financial reporting, duties of the issuer's management and auditor)
• NIST SP 800-53 audit and accountability controls used in FedRAMP authorizations (duties of the cloud service provider and agency)

Verdifax records can serve as evidence for those parties' own controls. Whether that evidence is sufficient is for the organization and its auditors or regulators, and using Verdifax does not by itself make any organization compliant. Verdifax is not FedRAMP certified and does not currently hold a SOC 2 report or an ISO/IEC 27001 certificate.

The narrowness is the credibility.

Continue

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