`ExecutionManifest`

Pydantic model representing the full sealed manifest. The Go API serializes these fields in PascalCase; the SDK exposes them in snake_case via Pydantic field aliases, both naming styles work.

Import

from verdifax import ExecutionManifest

Fields

Field	Type	Stage	Notes
`envelope_id`	`str`	1 (DOG)
`envelope_hash`	`str`	1 (DOG)	64-char hex
`sequence_id`	`str`	2 (DTL)
`transport_hash`	`str`	2 (DTL)	64-char hex
`epa_hash`	`str`	3 (DKEC)	64-char hex
`efa_hash`	`str`	3 (DKEC)	64-char hex
`execution_ids`	`List[str]`	3 (DKEC)	Six entries, DSE, TOK, DSC, NREP, AIVP, DCAE
`aer_hash`	`str`	4 (AER)	64-char hex
`transcript_hash`	`str`	5 (ZKSP, ZK transcript)	64-char hex
`hardware_attestation_hash`	`str`	5 (ZKSP, hardware attestation)	64-char hex; designed for TPM2 / SEV-SNP measurement. Scaffold today, see scaffold-gaps
`leakage_bundle_hash`	`str`	5 (ZKSP, leakage bound)	64-char hex
`formal_verifier_status`	`str`	5 (ZKSP, formal verifier)	Carries the formal-verifier success token. Scaffold today, see scaffold-gaps
`zksp_binding_hash`	`str`	6 (Sealing)	64-char hex
`migration_token_hash`	`str`	6 (Sealing)	64-char hex
`replay_fingerprint`	`str`	6 (Sealing)	64-char hex
`pote_proof_hash`	`str`	7 (Ledger)	64-char hex
`log_entry_id`	`str`	7 (Ledger)	Rekor-style id
`registry_artifact_count`	`int`	8 (Registry)	Should be 18
`final_vfa_hash`	`str`	9 (DLA)	64-char hex
`independent_verified`	`bool`	9 (DLA)	Must be `True` for a sealed manifest
`manifest_hash`	`str`	(seal)	The headline 64-char hex

Methods

manifest.kernel_executions() -> dict[str, str]
# → {"DSE": "...", "TOK": "...", "DSC": "...", "NREP": "...", "AIVP": "...", "DCAE": "..."}

manifest.stages() -> list[StageResult]
# → 9-element list, one per pipeline stage

list(manifest)  # iter, same as .stages()

Validation

Constructing an ExecutionManifest via ExecutionManifest.model_validate(...) enforces:

execution_ids has exactly 6 entries
registry_artifact_count is non-negative
All required fields are present

Invalid responses raise Pydantic's ValidationError.

Manifest structure for non-OK runs

For non-OK runs (pepg_deny, ccv_halt, macc_halt), the persisted JSON wraps the partial manifest under a manifest key alongside the sealed receipt:

{
  "manifest": {
    "partial": true,
    "halted_at_phase": "DKEC",
    ...
  },
  "deny_receipt": { ... },
  "ccv_halt_receipt": { ... },
  "macc_halt_receipt": { ... }
}

When fetching from /runs/{id}/artifacts via the HTTP API, use the outcome_kind field on the run summary to branch on which receipt key to read. The SDK's typed exceptions handle this automatically.