VerdifaX

Sample audit response

When a regulator, auditor, or counterparty asks "show me how this AI decision was made," the response template below is what you send. Adapt to the specific framework and tone, but the structural elements are the same.

The scenario

A health-insurance plan uses an AI system to assist with prior-authorization decisions. A patient files a complaint after a denial. The state insurance regulator opens a data request: produce evidence of how the AI evaluated the case.

What to include in the response

1. Cover letter (1 page)

Identify the system, the decision, the date, the patient (or de-identified surrogate), and the regulator's reference number. Conclude with: "Cryptographic evidence of this decision is provided as Exhibit A. The sealed record of the decision is independently verifiable using the procedure in Section 3."

2. Exhibit A, Verdifax audit report

Fetch the PDF for the run:

curl -s https://your-orchestrator/runs/{id}/report.pdf \
  -H "X-Verdifax-Key: vfx_..." \
  -o exhibit-A-verdifax-audit.pdf

The PDF contains:

  • The Verdifax wordmark and run number
  • Date and duration of the decision
  • The full sealed ManifestHash
  • Run metadata (program id, route id, payload hash, status)
  • The sealed manifest fields
  • The six DKEC kernel execution IDs
  • Regulatory-mapping section (EU AI Act / HIPAA / SOX, as relevant)
  • Verification statement
  • QR code linking to the public verify page for the run

Export the run's sealed audit bundle alongside the PDF as Exhibit A-2; Section 3 shows how.

3. Section 3, Independent verification procedure (outcome-aware)

This is the part that makes the evidence chain credible. Describe the procedure based on the run's outcome:

For OK runs (AllowToken):

The cryptographic seal in Exhibit A may be independently verified by any party holding the run's sealed audit bundle, provided as Exhibit A-2. Once the reviewer holds the bundle, verification does not require access to our systems, our databases, or our staff, and does not require the original input.

Procedure for OK outcome:

  1. We export the run's sealed audit bundle as Exhibit A-2: 
    curl -s -H "X-Verdifax-Key: $VERDIFAX_KEY" \
  https://api.verdifax.com/runs/{id}/artifacts -o exhibit-A2-bundle.json
  2. The reviewer installs the open-source verifier, v0.14.5 or later, with go install github.com/Verdifax/verdifax-verify@latest, or downloads a Cosign-signed release binary (see Verify a Verdifax audit bundle).
  3. The reviewer runs, on their own machine: 
    verdifax-verify exhibit-A2-bundle.json
  4. Exit code 0 means every section hash, the bundle hash and, for an anchored run (the production default), the pre-anchor digest and the anchored public-log leaves recompute from the bundle's own fields, and every section is bound to the same manifest hash shown in Exhibit A. The verifier does not recompute the manifest hash itself. With verdifax-verify 0.14.5 or later, the verdict line VERIFIED AND ANCHORED, COMPLETE RECORD ANCHORED means a second public-log entry binds every section of the record. Successful runs from run 238 on receive it. From run 239 on, a missing or altered second entry is a failure (exit code 1); for run 238 the reviewer should require this verdict, because deleting its second entry yields PARTIAL COVERAGE with exit code 0. VERIFIED AND ANCHORED, PARTIAL COVERAGE means the run identity and the 33-value pre-anchor table are anchored but the descriptive sections (outcome summary, request substance, authorization and approval chain, real-world effects, system provenance) are not.
  5. As the operator, we additionally confirm the manifest seal server-side with verdifax.verify_run(run_id) (GET /runs/{id}/verify), which re-derives the manifest hash from the run's stored manifest fields and compares it with the recorded seal (result.verified is True). This step runs on the Verdifax server and is a self-check, not an independent one.

Re-running the original input through Verdifax is not a verification method: each record binds its own admission clock, nonce, and public-log entry, so a replay can never reproduce a production record's manifest hash. Production records are verified by recomputation, as above.

For PEPG Deny runs (DenyReceipt):

The sealed denial in Exhibit A records that the request was refused at the pre-execution policy gate before any Verdifax pipeline stage after the gateway ran. It does not show whether the organization's own AI model was invoked before the request was submitted.

Procedure for PEPG deny outcome:

  1. Fetch the sealed DenyReceipt: 
    curl -H "X-Verdifax-Key: $VERDIFAX_KEY" \
  https://api.verdifax.com/runs/{id}/deny-receipt -o deny.json
  2. Verify the receipt and its public-log entry with verdifax-verify 0.14.5 or later (receipts issued before run 241, at 23:11 UTC on 2026-10-16, when receipt anchoring started, carry no entry and are reported as self-consistent only; receipts anchored under receipt anchor v2 also bind the run number): 
    verdifax-verify deny.json
  3. A green checkmark confirms that the receipt hash recomputes from the receipt's own fields. The fired_rule_id and decision_reason_code are part of that hash, so changing either one without also recomputing the hash makes the check fail.

For CCV Halt runs (CCVHaltReceipt):

The sealed halt receipt in Exhibit A records that the request was admitted under policy, the kernels executed, and the per-run budget was then found breached at the post-DKEC check, using the token consumption the caller declared in the request. The system halted the run and sealed the partial state.

Procedure for CCV halt outcome:

  1. Fetch the sealed CCVHaltReceipt: 
    curl -H "X-Verdifax-Key: $VERDIFAX_KEY" \
  https://api.verdifax.com/runs/{id}/ccv-halt-receipt -o ccv_halt.json
  2. Verify the receipt seal: 
    verdifax-verify ccv_halt.json
  3. The consumed_at_halt field shows the budget consumed before the halt. The partial_execution_hash is the sealed state of work completed.

For MACC Halt runs (MACCHaltReceipt):

The sealed halt receipt in Exhibit A records that the tenant's cumulative budget was at or beyond the configured limit at execution time. The run halted after the DKEC kernels had executed and before the AER stage; no later stage ran.

Procedure for MACC halt outcome:

  1. Fetch the sealed MACCHaltReceipt: 
    curl -H "X-Verdifax-Key: $VERDIFAX_KEY" \
  https://api.verdifax.com/runs/{id}/macc-halt-receipt -o macc_halt.json
  2. Verify the receipt seal: 
    verdifax-verify macc_halt.json
  3. The cumulative_at_halt field shows total consumption across all runs in the window. The window_start and budget_limit are sealed in the receipt, recording the enforcement configuration at halt time.

4. Honest scope statement

Include this paragraph verbatim:

The cryptographic seal shows that the run's audit bundle is internally consistent: every section hash recomputes byte-for-byte from the bundle's own fields and every section is bound to the same manifest hash. For an anchored run sealed from run 238 on that verifies as COMPLETE RECORD ANCHORED, a second entry on the public Sigstore Rekor log binds every section of the record, so no section has been altered since anchoring. [For a run sealed before run 238 under leaf v5, replace the previous sentence with: the entry on the public Sigstore Rekor log 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, so those values have not been altered since sealing; the descriptive sections 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.] The seal does not certify that the AI system's recommendation was clinically or substantively correct, that determination remains a question of professional judgment and is addressed in [other governance documentation, attached as Exhibit B]. This report records the events described. It is not a conformity assessment, certification, audit opinion or legal opinion.

This honesty is the credibility move. Regulators see overstated cryptographic claims constantly; precise scoping reads as serious work.

5. Optional, third-party attestation

If you have an external auditor that has independently verified the same hash, include their letter. This converts your evidence chain from "we say so" to "we say so, and an independent firm with reputational stake confirms."

The pattern, abstracted

Every audit response, regardless of regulatory framework, follows the same shape:

  1. Identify the specific decision under review
  2. Provide the Verdifax PDF as primary evidence
  3. Document the independent-verification procedure
  4. Scope what the cryptographic claim covers and does not cover
  5. Optional third-party verification letter

Continue