VerdifaX

The nine stages

Every Verdifax execution flows through nine deterministic stages, each contributing its hash output to the final sealed manifest. This page walks through each stage in plain English. The full technical specification is in the Section 0 reference.

Stage 1 — DOG (Deterministic Oracle Gateway)

The pipeline's front door. DOG admits the payload, derives an envelope identifier, and computes the envelope hash — a sealed snapshot of the input bytes plus the program identity. Nothing is admitted that hasn't been canonically encoded first.

What DOG checks: the bytes are well-formed, the program is authorized by the registry, and the same input cannot be admitted twice without detection. What DOG does not check: whether the values inside the input are truthful. A well-formed patient record with fabricated symptoms is admitted the same as a real one — authenticity of content is upstream of the pipeline.

Outputs added to the manifest: envelope_id, envelope_hash.

Stage 2 — DTL (Deterministic Transport Layer)

DTL produces a sequence id and a transport hash that bind the envelope into a totally-ordered log. The same envelope cannot enter the pipeline twice without being detected; the order in which envelopes enter is itself sealed.

Outputs: sequence_id, transport_hash.

Stage 3 — DKEC (Deterministic Kernel Execution Controller)

DKEC dispatches the six kernels that actually do the work. Each kernel runs deterministically and emits an execution id:

  • DSE — Deterministic State Engine
  • TOK — Temporal Ordering Kernel
  • DSC — Deterministic State Continuity
  • NREP — Non-Repudiation Engine
  • AIVP — Artificial Intelligence Verification Protocol (Tier 4)
  • DCAE — Deterministic Compute Attestation Engine

DKEC also emits an EPA hash (execution-plan-attestation) and an EFA hash (execution-final-attestation).

Outputs: epa_hash, efa_hash, six execution_ids.

Stage 4 — AER (Agent Execution Record)

AER consolidates the six kernel outputs into a single tamper-evident record. The AER hash seals the kernel-level work and is the input into the cryptographic sealing pipeline that follows.

Outputs: aer_hash.

Stage 5 — ZKSP L7 → L10

The cryptographic core. ZKSP runs four sub-stages in lockstep:

  • L7 computes a transcript hash — a Fiat-Shamir-style commitment to the entire execution trace.
  • L8 captures the hardware attestation hash — a TPM2 quote or AMD SEV-SNP measurement that anchors the run to a specific physical machine.
  • L9 produces a leakage bundle hash — an upper bound on information that escaped the secure enclave.
  • L10 runs the formal verifier, which must return the literal string VERIFIED_SOUND_COMPLETE_ZK for the run to seal. Anything else causes the manifest to be rejected.

Outputs: transcript_hash, hardware_attestation_hash, leakage_bundle_hash, formal_verifier_status.

Stage 6 — Phase 4 Proofs

This stage produces three artifacts that bind the AER + ZKSP results into a single proof bundle:

  • ZKSP binding hash — ties the ZK transcript to the registry record hash, ensuring the run was authorized by the program registry.
  • Migration token hash — a cross-environment portability seal so the proof can be re-verified on a different machine class without ambiguity.
  • Replay fingerprint — a deterministic identifier any re-execution must reproduce.

Outputs: zksp_binding_hash, migration_token_hash, replay_fingerprint.

Stage 7 — Ledger

The run is anchored into a transparency log. The PoTE (Proof of Tamper-Evident) proof hash binds the run to a Merkle inclusion proof in the public ledger. The log entry id is the human-readable reference (Rekor-style).

Outputs: pote_proof_hash, log_entry_id.

Stage 8 — Artifact Registry

Every artifact produced by the prior stages is registered into the artifact store. The registry returns a count — registry_artifact_count — that must equal the number of artifacts the orchestrator believed it produced. Mismatches abort the run.

Outputs: registry_artifact_count.

Stage 9 — DLA / .VFA

The final stage assembles everything into a single signed file: the .VFA artifact (Verdifax Final Artifact). An independent third-party verifier re-derives the chain and either signs off (independent_verified = true) or rejects.

Outputs: final_vfa_hash, independent_verified.

The seal

After Stage 9, all 18 hash fields plus formal_verifier_status plus registry_artifact_count plus independent_verified are concatenated in canonical order and SHA-256'd. The result is the manifest hash — the single 64-character receipt that anyone can verify.

sha256(
  envelope_id . envelope_hash .
  sequence_id . transport_hash .
  epa_hash . efa_hash .
  exec_ids[6] .
  aer_hash .
  transcript_hash . hw_attest_hash . leakage_hash . formal_verifier_status .
  zksp_binding_hash . migration_token_hash . replay_fingerprint .
  pote_proof_hash . log_entry_id .
  registry_artifact_count .
  final_vfa_hash . independent_verified
)  →  manifest_hash

Continue