GET /runs/{id}/report.pdf
Generates a comprehensive audit report PDF for the specified run. The PDF is outcome-aware: different content and proofs depending on whether the run resolved to ok, pepg_deny, ccv_halt, macc_halt, aivp_t4_halt, attestation_gap or stage_error.
Print-ready, single-file, rendered in the following order:
Request
GET /runs/{id}/report.pdf
X-Verdifax-Key: vfx_...
Response
200 OK:
Content-Type: application/pdf
Content-Disposition: attachment; filename="verdifax-audit-run-42-comprehensive.pdf"
The filename ends with the report format, set by the optional format
query parameter (brief, auditor, legal, or comprehensive, the
default).
The body is the PDF binary, typically about 400 to 450 KB in any of the four formats.
Example
curl -s http://localhost:9090/runs/42/report.pdf \
-H "X-Verdifax-Key: vfx_..." \
-o /tmp/verdifax-audit-run-42.pdf
open /tmp/verdifax-audit-run-42.pdf
PDF anatomy
Every Verdifax audit PDF follows this structure:
1. Executive Summary (two paragraphs)
First paragraph: Run-specific opener with timestamps, artifact hash prefix, actor, model.
Second paragraph: Outcome-aware infrastructure framing. Sample framings:
- ok: "This artifact records that the request was permitted under active policy, the system executed without deviation, and the tenant was within enforced constraints at execution time. It can be checked offline with the open-source verifier: where the run is anchored to the public log, the run's identity and, for records sealed since leaf v5, its pre-anchor values (33 on leaf v5, including the policy-gate outcome; leaf v6 adds a 34th stating that a complete-record anchor is required; leaf v7 adds a 35th sealing the anchoring window) are bound to that entry, so changing them no longer matches it. The descriptive sections are sealed by hashes inside the bundle but are not yet bound to the public-log entry." When the run carries a verified complete-record anchor (records sealed from run 238 on), the last sentence instead reads "...sealed by hashes inside the bundle and, through the anchored record digest, bound to the second public-log entry."
- pepg_deny: "This artifact records that a specific deny rule fired before execution and that the system halted at the policy gate without producing a full execution manifest. The sealed denial receipt's hash recomputes from the receipt's own fields."
- ccv_halt: "This artifact records that the request was admitted under active policy, that the per-run runtime budget was breached during execution, and that the system halted at the constraint boundary. The sealed halt receipt's hash recomputes from the receipt's own fields."
- macc_halt: "This artifact records that the request was admitted under active policy, that the bound tenant's cumulative budget was at or beyond cap at execution time, and that the system halted at the cumulative-constraint boundary. The sealed halt receipt's hash recomputes from the receipt's own fields."
For these outcomes, and for AIVP-T4 halts and attestation gaps, the PDF then states whether this run's receipt is anchored on the public log and at which entry, or that it carries no entry (receipts issued before run 241, at 23:11 UTC on 2026-10-16, when receipt anchoring started, carry none). For a receipt anchored under receipt anchor v2 it adds that the entry binds the run number and that removing it fails; for a v1 entry, that it does not bind the run number; and for a receipt that requires an entry but has none, that it verifies as FAILED while the refusal itself stands.
- stage_error: "This document records a pipeline failure for operational diagnosis only. No sealed manifest was produced; this record is not a verifiable execution attestation and should not be relied on as legal evidence of execution."
What an offline check confirms depends on when the run was sealed. For an anchored OK run sealed from run 238 on that verifies as COMPLETE RECORD ANCHORED, a second public-log entry binds every section of the bundle, including the descriptive sections the PDF renders. For an earlier run sealed under leaf v5, the public-log entry binds the run's identity and its 33 pre-anchor values, which include the attested decision, the AIVP governance result, the payload hash, the actor and the scaffold flags; the descriptive sections the PDF renders (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 they show the bundle is internally consistent, not that a party able to rewrite the whole bundle has not changed them. For a deny or halt run, verdifax-verify 0.14.5 or later confirms that the receipt's hash recomputes from the receipt's own fields and checks its public-log entry, when it has one. The per-claim and compile hashes in the PDF's Legal Evidence Artifact section are produced by Verdifax's LTC engine at render time and cannot be recomputed with the open-source verifier.
2. ENFORCEMENT NOT OBSERVATION callout
"Verdifax enforces execution, it does not only observe it. A request the policy gate refuses stops before any kernel runs; a run that breaches a budget or fails the AI governance review stops after its kernels and before its execution record. Either way a sealed receipt is produced instead of a full record."
Followed by a smaller italic line: "Sealed deny and halt receipts use the same canonical-preimage format as the manifest above. Each receipt's hash recomputes from its own fields; the Executive Summary states whether this run's receipt carries a public-log entry."
3. How to Verify callout
verdifax-verify --show-evidence-summary https://api.verdifax.com/public/runs/{token}/bundle.json
4. Outcome-specific sections
For OK runs: Decision section, Outcome Summary, Model & Execution Context (with MODEL ATTESTATION STATUS sub-block), Policy Evaluation Summary, Policy Evaluation Detail, Plain-English Interpretation, Policy → Outcome Binding, Authorization Summary (with AUTHORIZATION REQUIREMENT sub-block), Approval Chain, Risk Assessment, Request Substance, Runtime Budget State, Tenant Budget Snapshot, At-Execution Tenant State (sealed, with era version note), Real-World Effect (effect_log or "No external system action attested").
For non-OK runs: The corresponding Sealed Receipt section (DenyReceipt, CCVHaltReceipt, or MACCHaltReceipt).
5. OUTCOME-AWARE PROOF section
The title and banner vary by outcome:
- ok: Title "Proof, Cryptographic Seal", banner "MANIFEST HASH SHA-256" + manifest_hash
- pepg_deny: Title "Proof, Deny Receipt Seal", banner "DENY RECEIPT HASH SHA-256" + receipt.hash + disclosure paragraph
- ccv_halt: Title "Proof, CCV Halt Receipt Seal", banner "CCV HALT RECEIPT HASH SHA-256" + receipt.hash
- macc_halt: Title "Proof, MACC Halt Receipt Seal", banner "MACC HALT RECEIPT HASH SHA-256" + receipt.hash
6. Run Metadata table
Contains field "Pipeline Duration" (NOT "Duration (ms)"). The measured window wraps the whole pipeline. Sample values:
- For runs of one millisecond or more: "12 ms (12.345 ms wall-clock)"
- For sub-millisecond runs: a value such as "0.413 ms" with a sub-millisecond note
- For legacy v2-schema runs without duration_micros: "12 ms (legacy v2 schema; sub-millisecond precision unavailable)"
- For runs with both durations as 0: "< 1 ms" with a sub-millisecond note
A sub-millisecond value means no model call happened inside the measured window on that run. It does not mean Verdifax never calls a model: when the AIVP-T4 governance stage runs with the live-claude-api adapter, it sends the declared AI output to the live Anthropic Claude API inside this window, and the duration reflects that call.
7. Sealed Manifest Fields OR Pipeline Execution State
For OK: 18-row table with all pipeline-stage hashes.
For pepg_deny: "Not applicable, execution halted at the Pre-Execution Policy Gate (PEPG) before any pipeline stage produced a sealed artifact. No downstream pipeline artifacts (DTL transport hash, DKEC kernel execution IDs, AER, ZK transcript, hardware attestation, formal-verifier status, ledger entry, final VFA artifact) exist for this run. The DenyReceipt above is the complete sealed evidence of this outcome."
For ccv_halt/macc_halt: Similar note indicating which stages DID run before the halt.
8. Outcome-aware Verification Statement
A different text for each outcome state, dispatched on outcome_kind. See Errors for exact wording.
Use cases
- Attaching to a regulator's data request
- Including in an internal change-management ticket as evidence
- Sending to a counterparty as evidence of a recorded model decision
- Long-term archival alongside the model output it records
Sample PDFs
GET /runs/{id}/report.pdf is served only to the API key that
created the run; any other caller gets 401 or 404. There are
therefore no public download links for sample PDFs here. To see one,
run an attestation with your own key and download its report.
