Outcome states & sealed artifacts

Why six states (and not just "did it run?")

The original Verdifax nine-stage pipeline answered one question: did this AI execution happen the way you said it happened? That's the core attestation guarantee, the sealed ManifestHash, which every section of the run's audit bundle is bound to and which GET /runs/{id}/verify re-derives from the stored manifest fields.

Five additional checks extend that guarantee to the questions that operators, regulators, and counterparties actually ask in production:

• PEPG, Should this call have happened at all? A pre-execution policy gate evaluates a Policy Specification Language (PSL) rule set against the request at stage 1.5, right after the DOG envelope stage and before any kernel executes. The hosted API runs one built-in rule set whose single rule, baseline-permit, admits every request, so it denies only when Malicious Code Defense (MCD) matches a threat signature.
• CCV, Should this call still continue? A constraint verifier checks the run's per-run token budget at the post-DKEC boundary and halts the run when it is breached. The consumption it counts is caller-declared (request_substance.cost.total_tokens); a run that reports none counts as zero.
• MACC, Has the tenant exceeded its cumulative limit? A multi-agent coordination constraint tracks the same caller-declared consumption across all runs in one budget bucket and halts when the cumulative budget is exhausted. From run 247 on, the bucket is the authenticated API key (api-key-N, or anonymous without a key). Before run 247, it was the caller-declared attested_context.actor_id when one was supplied, falling back to api-key-N.
• AIVP-T4, Is the AI output acceptable? An AI governance review checks the AI output text a run carries and halts the run before the execution record when it refuses the output.
• Attestation gap check, Does the request carry what policy requires? At admission, before the pipeline begins, a policy can require specific attested fields; a request missing them is refused. The hosted API's built-in policy requires no attested fields, so the hosted API does not currently produce this outcome.

Each enforcement point produces its own sealed artifact. The CCV and MACC halt receipts carry the allow_token_hash of the AllowToken that admitted the run, so each halt links back to the admission decision.

The six outcome states

MCD-driven denies are not a separate state

When Malicious Code Defense (MCD) matches a curated code-attack signature in the request payload, the outcome is still pepg_deny. The difference is that the DenyReceipt carries a populated mcd_finding_hash field that binds the matching threat signature into the seal. The decision reason code will be MCD_SIGNATURE_MATCH. This is one outcome with multiple decision paths, not a distinct state.

Exception: stage_error

A stage_error state exists for pipeline crashes, when the run fails before any sealed artifact could be assembled (e.g., a disk write failure in the orchestrator, not a policy/budget decision). It is intentionally not treated as an outcome state, it is an exception. Run records with stage_error are auditable but unsealed.

Where each gate fits in the pipeline

Caller request
    │
    ▼
[ Attestation gap check ] ── missing fields ──► AttestationGapReceipt (sealed)
    │
    ▼
DOG (stage 1)
    │
    ▼
[ PEPG, stage 1.5 ] ── deny ──► DenyReceipt (sealed)
    │ allow (AllowToken, sealed inside the manifest)
    ▼
Program authorization → DTL → DKEC (kernels execute)
    │
    ▼
[ CCV, stage 3.5 ] ── halt ──► CCVHaltReceipt (sealed)
    │
    ▼
[ MACC, stage 3.6 ] ── cumulative halt ──► MACCHaltReceipt (sealed)
    │
    ▼
[ AIVP-T4, stage 3.7 ] ── refuse ──► AivpT4HaltReceipt (sealed)
    │
    ▼
AER → ZKSP → Proof & state binding → Ledger → Registry → DLA
    │
    ▼
run completes → ExecutionManifest (sealed)

Governance checkpoints:

• Attestation gap check, Runs at admission, before the pipeline. Decision: proceed or attestation_gap.
• PEPG, Stage 1.5, after DOG and before any kernel executes. Decision: ok (allow) or pepg_deny (reject).
• CCV, A single check at the post-DKEC boundary (stage 3.5), after the kernels have executed. Compares the run's caller-declared consumption with the per-run budget. Decision: proceed or ccv_halt.
• MACC, Stage 3.6, after CCV and before AER. Checks the bucket's cumulative caller-declared consumption against the per-window limit. Decision: proceed or macc_halt.
• AIVP-T4, Stage 3.7, after MACC and before AER. Decision: release or aivp_t4_halt.

An ok outcome means every configured gate let the run through and the nine-stage pipeline ran to completion. Non-OK outcomes each carry a sealed artifact proving why execution stopped.

What each artifact seals

Each sealed artifact is a canonical-bytes record (RFC 8785 + SHA-256) containing exactly the fields a third party needs to replay the decision. Signatures and other transient attestation fields are excluded from the sealed hash, that's the §0 detached-attestation corollary. Re-signing or re-issuing the artifact never invalidates the seal.

Common fields across all six artifact types:

• envelope_id, the EnvelopeV2 identifier the decision applies to
• evaluator_version, which evaluator implementation made the call (e.g. pepg-0.3.0, ccv-0.3.0, macc-0.3.0)
• version, the artifact schema version (e.g. vfa.deny_receipt.v1)
• hash, the SHA-256 of the canonical preimage (the seal itself)
• *_clock, RFC3339 timestamp when the decision was made

State-specific fields:

The CCV and MACC halt receipts both carry the allow_token_hash of the AllowToken that initially authorized the run, so the full causal chain (admitted, then halted on runtime / cumulative evidence) is preserved in a single auditable record.

How to retrieve the artifact for a run

Each outcome state has its own REST endpoint. The dashboard at verdifax.com/app/artifact/?id=N and the audit PDF auto-select the right one based on the run's outcome_kind:

GET /runs/{id}/allow-token
GET /runs/{id}/deny-receipt
GET /runs/{id}/ccv-halt-receipt
GET /runs/{id}/macc-halt-receipt
GET /runs/{id}/aivp-t4-halt-receipt
GET /runs/{id}/attestation-gap-receipt

Each returns { "ok": true, "run_id": <id>, "<artifact_key>": { ... } }. A 404 indicates the run was not of the matching outcome state.

How a third party verifies the seal

verdifax-verify 0.14.5 or later re-derives a sealed receipt's hash from its canonical preimage and checks the receipt's public-log entry, including who logged it and when; under receipt anchor v2 the entry also binds the run number, and the receipt states that it must carry the entry. Fetching a receipt needs the API key that created the run; 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. The customer dashboard and audit PDF emit the exact copy-pasteable command for each artifact:

curl -H "X-Verdifax-Key: $VERDIFAX_KEY" \
  https://api.verdifax.com/runs/42/deny-receipt \
  -o receipt.json
verdifax-verify receipt.json

Replace deny-receipt / .deny_receipt with the matching endpoint and key for the other outcomes.

Governance options

PEPG, CCV, and MACC are independent. A deployment can adopt any subset.

• PEPG only, useful when the operator already has a structured authorization policy and wants pre-execution enforcement plus a sealed record of every admit/deny decision. Outcomes: ok or pepg_deny.
• PEPG + CCV, adds per-run budget protection: if a run's caller-declared token consumption exceeds the configured limit, CCV halts it at the post-DKEC check with a sealed receipt. Outcomes: ok, pepg_deny, or ccv_halt.
• PEPG + CCV + MACC, adds cumulative governance per budget bucket (the API key, from run 247 on): even if every individual run passes its per-run budget, MACC halts runs once the bucket's caller-declared consumption reaches the per-window cap. Outcomes: all four (ok, pepg_deny, ccv_halt, macc_halt).
• Attestation only (no PEPG/CCV/MACC), the original nine-stage pipeline. Without PEPG there is no AllowToken, so GET /runs/{id}/allow-token returns 404. No policy gates, no budget enforcement. The AIVP-T4 governor is still wired, so the run's outcome is ok, aivp_t4_halt when the governor refuses AI output text the run carries, or stage_error on crash.

The AIVP-T4 governor is wired in every option above, so each of them can also end in aivp_t4_halt for a run that carries AI output text.

Specifications

The normative specifications for each gate live in the IP-protection estate:

• PEPG_PSL_SPEC v0.2, PSL grammar, evaluator algorithm, AllowToken and DenyReceipt schemas, signing + threshold rules, §0 detached- attestation corollary
• CCV_SPEC v0, per-run budget grammar, monitor algorithm, CCVHaltReceipt schema
• MACC_SPEC v0, cumulative budget grammar, coordinator algorithm, MACCHaltReceipt schema, tenant scoping