Outcome states & sealed artifacts

Why four 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 that any third party can re-derive.

Three additional phases 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 before the pipeline runs.
• CCV, Should this call still continue? A continuous constraint verifier monitors per-run budgets, tokens, time, cost, and halts the run when a budget is breached.
• MACC, Has the tenant exceeded its cumulative limit? A multi-agent coordination constraint tracks consumption across all runs sharing a tenant identifier and halts when the cumulative budget is exhausted.

Each enforcement point produces its own sealed artifact, and every artifact binds back to the manifest hash so the full causal chain is provable.

The four outcome states

MCD-driven denies are not a separate state

When the Malicious-Content Detector (MCD) matches a curated threat signature, 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
    │
    ▼
[ PEPG ]  ── deny ──► DenyReceipt (sealed)         ← PEPG
    │
  allow
    ▼
[ MACC gate ] ── cumulative halt ──► MACCHaltReceipt    ← MACC
    │                                (sealed)
  within budget
    ▼
DOG → DTL → DKEC → AER → ZKSP → Sealing → Ledger → Registry → DLA
                    │                                            │
                    ▼                                            ▼
                [ CCV ] ── halt ──► CCVHaltReceipt          AllowToken
                    │              (sealed)                  (sealed,
                  pass                                       inside manifest)
                    ▼
                run completes → ExecutionManifest (sealed)

Governance checkpoints:

• PEPG, Runs before any pipeline work. Pre-execution policy gate evaluates the request. Decision: ok (allow) or pepg_deny (reject).
• MACC, Consulted after PEPG allows but before pipeline execution. Checks cumulative tenant budget against per-window limit. Decision: ok (proceed) or macc_halt (reject).
• Nine-stage pipeline, Executes (if PEPG and MACC both allow).
• CCV, Runs continuously during the nine-stage pipeline. Monitors per-run budgets. Decision: ok (complete) or ccv_halt (stop mid-flight).

An ok outcome means PEPG allowed, MACC allowed, the nine-stage pipeline ran to completion, and CCV's per-run budgets were not breached. 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 four 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 app.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

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

The open-source MIT-licensed verdifax-pepg-verify CLI re-derives every sealed hash from the canonical preimage, with no Verdifax credentials required. 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 \
  | jq .deny_receipt | verdifax-pepg-verify

Replace deny-receipt / .deny_receipt with the matching endpoint and key for the other three 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 an immutable record of every admit/deny decision. Outcomes: ok or pepg_deny.
• PEPG + CCV, adds runtime budget protection: if a model call exceeds the configured token/time/cost limit, CCV halts it mid-flight with a sealed receipt instead of letting it run away. Outcomes: ok, pepg_deny, or ccv_halt.
• PEPG + CCV + MACC, adds tenant-scoped cumulative governance: even if every individual run passes its per-run budget, MACC stops the tenant once they hit their daily/hourly/per-window cap. Outcomes: all four (ok, pepg_deny, ccv_halt, macc_halt).
• Attestation only (no PEPG/CCV/MACC), the original nine-stage pipeline guarantee: every admitted request produces a sealed ExecutionManifest with an AllowToken. The run's outcome is always ok (or stage_error on crash). No policy gates, no budget enforcement.

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