Glossary

AllowToken

Sealed artifact issued by PEPG when pre-execution policy admits a request. Carries the firing rule, the standardized decision_reason_code, the active policy_hash, the evaluation_hash binding envelope + policy + rule + outcome, and the evaluator_version. Per the §0 detached-attestation corollary, signatures are excluded from the seal, re-signing never invalidates an AllowToken.

AER, Attestation Execution Record

The record produced at Stage 4 of the pipeline. AER consolidates the six DKEC kernel outputs (DSE, TOK, DSC, NREP, AIVP, DCAE) into one signed object. Its hash, aer_hash, is the input to the cryptographic sealing pipeline (Stage 5) and is one of the values bound to the public-log entry. The descriptive decision record carried in the bundle's AER section (aer.decision) is covered by the complete-record anchor on records sealed from run 238 on; on earlier records it is sealed only by section hashes inside the bundle.

AIVP, Artificial Intelligence Verification Protocol

DKEC kernel that governs AI behavior under policy. Performs contradiction detection, policy enforcement, and reasoning validation; emits the Proof Integrity Artifact (PIA hash). Answers: "Did the AI behave correctly under governance rules?"

Attestation

In Verdifax usage, the act of sending a payload through the nine-stage pipeline and receiving back a sealed manifest hash. "Attesting" a model output means making that output verifiable.

CCV, Continuous Constraint Verification

The per-run budget check that runs once, at the post-DKEC boundary (stage 3.5), after the kernels have executed. Compares the run's consumption against a configured budget (token_budget, time_budget, or cost_budget) and emits a sealed CCVHaltReceipt when a limit is breached. The consumption it counts is caller-declared (request_substance.cost.total_tokens); a run that reports none counts as zero. The partial execution up to the halt point is sealed via partial_execution_hash.

CCVHaltReceipt

Sealed artifact issued by CCV when a per-run runtime budget is breached. Carries the original allow_token_hash (so the causal chain is preserved), the budget_hash of the active configuration, the breached budget_limit, the measured consumed_at_halt, the partial_execution_hash of work completed before the halt, and the constraint_type identifier (e.g., token_budget, humanized as "token" in audit PDFs).

DCAE, Deterministic Compute Attestation Engine

DKEC kernel. In each run its execution ID is a commitment hash over the envelope ID, the envelope hash and the DCAE engine version. The engine itself is a stateless check served at POST /dcae/verify: given a proof bundle, it confirms the required fields are present, that the ZKSP status is the disclosed scaffold token, and that the manifest hash recomputes from the supplied preimage, then returns a closure hash. It does not examine hardware attestation and does not show that a run executed on trusted hardware.

DKEC, Deterministic Kernel Execution Controller

Stage 3 of the pipeline. DSE, TOK and DSC execute here; the AIVP slot is filled with the governance stage's sealed PIA hash, and the NREP and DCAE slots are identity and closure commitments. Emits the EPA / EFA hashes plus six execution IDs.

DLA, Deterministic Ledger Anchoring

Stage 9. Produces the final .VFA artifact. The output is final_vfa_hash plus an independent_verified boolean that must be true for the manifest to seal; that flag comes from an in-process consistency check this build always sets to true, not from a third-party verifier.

DOG, Deterministic Oracle Gateway

Stage 1 of the pipeline. The pipeline's front door, admits the payload, derives the envelope, computes envelope_id and envelope_hash.

DSC, Deterministic State Continuity

DKEC kernel that validates state transitions. Answers: "Was this state transition valid?"

DSE, Deterministic State Engine

DKEC kernel that captures the exact system state at execution time. Answers: "What is the exact system state?"

DTL, Deterministic Transport Layer

Stage 2. Sequences and binds envelopes into a totally-ordered log; emits sequence_id and transport_hash.

DenyReceipt

Sealed artifact issued by PEPG when pre-execution policy rejects a request. Carries the firing rule (or the literal default when the policy's default effect was deny), the standardized decision_reason_code (e.g. RULE_DENIED, CLASSIFICATION_EXCEEDED, MFA_REQUIRED_NOT_SATISFIED, MCD_SIGNATURE_MATCH), the policy_hash, and the evaluation_hash. When the deny was driven by a MCD signature match, the receipt carries a populated mcd_finding_hash binding the matching threat signature; the decision_reason_code will be MCD_SIGNATURE_MATCH. MCD-driven denies are NOT a separate outcome state, they are pepg_deny with mcd_finding_hash populated.

EFA, Execution Flow Artifact

A DKEC output. The hash sealing the per-kernel execution chain (DSE, TOK, DSC, NREP, AIVP, DCAE in canonical order). Distinct from epa_hash, which captures the higher-level execution proof.

Envelope

The canonical wrapper for a payload that's been admitted into the pipeline. An envelope is identified by envelope_id (string) and sealed by envelope_hash (64-char hex).

EPA, Execution Proof Artifact

A DKEC output. The hash produced by Stage 3 summarizing successful kernel execution, captures the work the six kernels actually performed and is bound into the manifest.

Formal Verifier Status

A field in the sealed manifest carrying the ZKSP status token, today SCAFFOLD_R1CS_HASH_FACADE (records sealed before 2026-10-15 carry the legacy VERIFIED_SOUND_COMPLETE_ZK). Anything else aborts the manifest. Today this field is scaffold-flagged: see scaffold-gaps.

Hardware Attestation Hash

A Stage 5 (ZKSP) field. It is a legacy placeholder that ZKSP fills with a scaffold value. Real hardware evidence exists only on deployments with an AMD SEV-SNP attestation agent configured: there the execution record's hardware field is the SHA-256 of a verified SEV-SNP report taken before the record is built, and the bundle's hardware_attestation section clears its scaffold flag. The hosted service runs without an agent today, and TPM2 is not implemented. See scaffold-gaps.

Leakage Bundle Hash

Stage 5 (ZKSP, leakage bound) output, designed to seal an upper bound on information that escaped the secure enclave during the run. Today it is a scaffold value, flagged as such in every bundle.

Manifest Hash

The headline artifact of every Verdifax run. A 64-character lowercase SHA-256 hex digest computed from every other field in the ExecutionManifest. The open-source verifier confirms that every section of the audit bundle carries this value; re-deriving the hash itself takes the full stored manifest, which GET /runs/{id}/verify does server-side. The manifest does not cover the authorization chain, the causal graph and real-world effects, the request substance, or the system provenance.

MACC, Multi-Agent Coordination Constraint

A stateful cumulative budget enforcer that runs after CCV passes (stage 3.6, before AER). MACC tracks caller-declared consumption (request_substance.cost.total_tokens; a run that reports none counts as zero) across all runs in one budget bucket against a per-window cumulative budget (e.g. cumulative_token_budget per day). 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 supplied, falling back to api-key-N. When the cumulative limit is breached, MACC emits a sealed MACCHaltReceipt and halts the run.

MACCHaltReceipt

Sealed artifact issued by MACC. Carries the budget bucket as tenant_id, the active window_start, the cumulative budget_limit, the measured cumulative_at_halt, the contributing run's per_run_consumption, the budget_hash, the constraint_type identifier (e.g., cumulative_token_budget, humanized as "token" in audit PDFs), and the original allow_token_hash of the run that tipped the cumulative consumption past the limit.

outcome_kind

A string field on every run summary (GET /runs and GET /runs/search) indicating which sealed artifact endpoint to fetch. One of: ok, pepg_deny, ccv_halt, macc_halt, aivp_t4_halt, attestation_gap, stage_error. The dashboard and audit PDF use this field to auto-select the correct endpoint and rendering.

MCD, Malicious Code Defense

A curated library of threat signatures (MCD_SIGNATURE_LIBRARY_V0.yaml and successors) plus a static analyzer that PEPG consults during evaluation. When a request matches a signature, MCD emits an MCDFinding which is bound into the resulting DenyReceipt via mcd_finding_hash. The library is built into the orchestrator binary. MCD also has a provenance-check component, but it is not enabled on the hosted service, so no provenance check runs there today.

NREP, Non-Repudiation Engine Protocol

DKEC kernel that binds execution to the actor that initiated it via an Ed25519 signature over the AER record. Answers: "Which API key's identity is this run attributed to?" Verdifax's server generates the key pair when the API key is created (older keys get one at first use) and holds the private key in its database, so the signature shows that Verdifax's server signed with the key assigned to that API key, not that the customer's own device or system signed. Signatures verifiable offline.

PEPG, Pre-Execution Policy Gate

The gate at stage 1.5, after the DOG envelope stage and before any kernel executes. PEPG evaluates a Policy Specification Language (PSL) policy against the incoming request and either issues a sealed AllowToken (admit) or a sealed DenyReceipt (reject). PEPG also consults the MCD library to detect known code-attack signatures in the request payload. The hosted API runs one built-in policy whose single rule, baseline-permit, admits every request, so its only denies are MCD signature matches. PEPG can be turned off entirely; when off, every admitted request becomes the original nine-stage attestation pipeline.

PIA, Proof Integrity Artifact

The hash produced by the AIVP kernel binding the AI behavior verification result. Included in the AER record as part of the kernel-level seal for any run involving an AI component.

PoTE, Proof of Temporal Execution

Stage 7 output. A Merkle inclusion proof in an append-only public transparency log for the run's leaf, which binds the run's identity values and, on records sealed under leaf v5, the digest of its 33 pre-anchor values. Records sealed from run 238 on also carry a second entry, the complete-record anchor, which binds a digest of every section of the record.

PSL, Policy Specification Language

The structured rule language PEPG evaluates. Defined in PEPG_PSL_SPEC v0.2. A PSL policy is a list of rules with predicates over the envelope plus a default effect (allow or deny). Policies can be Ed25519-signed with threshold rules (any / all / n_of_m / required) and bound to a TrustAnchorSet for revocation.

Program ID

A 64-character lowercase hex identifier the caller declares for the program being executed. On deployments that enforce the program registry it must match a registered program, or the run is refused before transport; otherwise it is bound into the run exactly as submitted. Runs of different programs always produce different manifest hashes.

Registry Record Hash

The §0 hash of the program registry record the caller declares for this program. Required as input to every attest() call. On deployments that enforce the program registry it is resolved against a registration before the run proceeds; otherwise it is bound into the run exactly as submitted, so the record proves the value was sealed, not that a program was registered. If the registry record changes (e.g., the program is updated), the hash changes, which is intentional.

Replay Fingerprint

Stage 6 output. A deterministic identifier any honest re-execution must reproduce.

Route ID

A free-form deterministic route identifier. Runs of the same program on different routes produce different manifest hashes.

VFA, Verdifax Final Artifact

The .vfa artifact produced at Stage 9, identified by final_vfa_hash, which is computed from the sealed outputs of every earlier stage.

ZKSP, Zero-Knowledge State Prover

Stage 5. It emits the ZK transcript, the hardware-attestation placeholder, the leakage bound, the formal-verifier status and the ZKSP binding hash. ZKSP is a disclosed scaffold: it emits a deterministic hash facade (SCAFFOLD_R1CS_HASH_FACADE) in place of a real zero-knowledge proof, and its binding hash commits to those scaffold values, not to a proof. Audit bundles flag the transcript, leakage and binding values as scaffold. See scaffold-gaps.

ZK Proof

The proof the ZKSP step is designed to produce: a zero-knowledge proof that the run satisfies the formal-verifier predicate without revealing the witness (the inputs, the model, or the runtime state). It is not implemented today; the step emits a disclosed hash facade instead, flagged as scaffold in every bundle.

ENFORCEMENT NOT OBSERVATION

An architectural claim: 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. Non-execution is as verifiable as execution.

Pipeline Execution State

A section of the audit PDF that appears for non-OK runs, replacing the "Sealed Manifest Fields" table. Describes which pipeline phases ran before the halt and which artifacts do not exist for this run.

at-execution tenant state

For OK runs, a sealed record of the tenant's cumulative consumption as measured at execution time, bound into the manifest. Added in a recent orchestrator release; runs created before that release do not include this field, and cumulative values for those runs must be reconstructed from coordinator records.

Pipeline Duration

A field in the audit PDF's Run Metadata table, showing wall-clock runtime in milliseconds with sub-millisecond precision via the duration_micros field. The measured window wraps the whole pipeline, so what it includes depends on the run. A sub-millisecond value, such as "0.413 ms", means no model call happened inside that window. That is a property of the run, not of Verdifax in general: 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. Verdifax does not produce the caller's AI output; the caller's application calls its own model before submitting.