VerdifaX

Scaffold gaps

Verdifax is honest about what it cannot yet do. The audit bundle carries three open scaffold flags today, one per artifact that returns a placeholder rather than a real cryptographic value. Each flag rolls up one or more named declarations the system emits about itself; every declaration is named explicitly in the code, surfaced in every audit bundle, and tracked in the project roadmap with a documented closing path. Running verdifax-verify --show-evidence-summary against any bundle prints the same three category names you see below.

We publish this page because we believe an attestation system that hides its limitations is worth less than one that names them publicly. A buyer or auditor reading a Verdifax audit bundle should know exactly what is real evidence, what is scaffold-grade, and what activates each scaffold value.

What a scaffold gap is

A scaffold value is a placeholder that a step of Verdifax emits when the underlying real implementation is not yet wired. Two examples:

  • The hardware attestation step emits a policy-scaffold record declaring the platform is not yet running on attested silicon. The fields are present and consistent, but they are not derived from a TPM2 quote or SEV-SNP report, they describe the system's belief about itself, not a hardware-rooted measurement.
  • The zero-knowledge step emits a deterministic transitional hash facade in place of a real STARK proof. The hash is byte-stable and replayable; what it isn't is a zero-knowledge proof a third party can check without trusting the orchestrator.

Scaffold values are the difference between "we're building something we don't yet have" and "we're hiding what we don't yet have." Verdifax does the first.

How to recognize scaffold values in your bundle

Every artifact in the audit bundle that involves a scaffold value carries a scaffold field with three keys:

"scaffold": {
  "is_scaffold": true,
  "activated_by": "phase 7 (live cloud, TPM2 / SEV-SNP)",
  "note": "Real attested hardware lands when..."
}

The independent verdifax-verify CLI flags these in its report (the [scaffold] tag next to each affected artifact) and supports a --strict mode that fails verification when any scaffold flag is set. High-trust environments should always use --strict, a passing strict-mode verification means every value in the bundle is rooted in real cryptography.

The three open scaffold categories

The three categories below are the artifact paths the verifier reports in its evidence summary. Each category contains one or more named declarations the orchestrator emits about itself; expand a category to see them.

1. Hardware attestation, hardware_attestation.scaffold

Why it's scaffold today. The orchestrator runs on a containerized cloud machine without confidential-compute features enabled. There is no TPM2 chip to query and no SEV-SNP report to fetch.

What activates the real value. Deploy the orchestrator to an AWS m6a, Azure DC2as_v5, or GCP n2d-standard-2 instance with SEV-SNP enabled and vTPM 2.0 attached, AND activate the certificate-chain-verification body in the orchestrator's hardware attester. The full procurement spec is documented internally; the production runbook is written; what's missing is a deployment engineer with TPM2/SEV-SNP experience to execute the deployment, and a cryptographer to write the chain-verification body (which parses TPMS_ATTEST blobs and verifies AMD VCEK signatures against pinned roots).

This category rolls up three named declarations the orchestrator emits:

  • REAL_TEE_QUOTE_NOT_BOUND, the audit bundle's hardware_attestation is not bound to a real Trusted Execution Environment quote. What you see in enclave_measurement and pcr_selection is the system's self-declaration, not a hardware-signed measurement.
  • PLATFORM_CERTIFICATE_CHAIN_NOT_VERIFIED, when a real TPM2 or SEV-SNP attestation arrives, it must be verified against a certificate chain rooted at the silicon vendor (Intel, AMD, or the cloud provider's CA). Without this verification, even a real attestation could be a forgery from a stolen TPM. No real attestation is arriving yet, so there is no chain to verify.
  • HARDWARE_BOUND_MODE_NOT_ENABLED_CURRENT_HORIZON, the umbrella declaration. The system runs in a software-only attestation mode and this flag stays true until the two declarations above both close.

2. ZK transcript, transcript.scaffold

Why it's scaffold today. The prover decision is made (a transparent, post-quantum-safe STARK system) and the circuit interface trait is committed, but the adapter that lifts our internal R1CS into the prover's trace format is not yet implemented.

What activates the real value. A cryptographer writes the AIR adapter, wires the prover, and validates determinism across three Rust toolchains. After this lands, the production build path produces real STARK proof bytes that any party with the verifier library can check, with no trust in Verdifax required. The detailed engineering plan, including the chosen library (winterfell), the committed integration trait, the proof-system parameters, and the five acceptance gates that must pass before the scaffold flag flips, is documented at /concepts/zk-roadmap/.

This category rolls up one named declaration:

  • REAL_ZK_VERIFIER_NOT_IMPLEMENTED, the zero-knowledge step's proof_material_hash is the canonical SHA-256 of the run's evaluation transcript, not a real STARK / PLONK / Groth16 proof. The hash is byte-stable and replayable but a third-party verifier can only check it by re-running the orchestrator, not by independently checking the proof bytes.

3. ZK-state-prover binding / formal verifier, zksp_binding.scaffold

Why it's scaffold today. The Lean 4 development tree is empty; only a placeholder README exists. The Rust adapter is in place behind a feature flag, but it returns a "Lean development not yet populated" error because there is no Lean source for it to invoke. The MockZkspAdapter therefore emits the success-state token deterministically; flipping the scaffold flag is gated on a real Lean theorem confirming the same token.

What activates the real value. A formal-methods engineer populates the Lean tree with the canonical encoding model, the pipeline specification, R1CS satisfiability lemmas, and the determinism proof. The theorem signature is frozen so the Rust adapter's expected hash constant can be filled in lock-step. After this lands, the formal verifier reports the success token only when the Lean development confirms the theorem, and the artifact viewer drops the SCAFFOLD badge from the Formal Verifier Status row.

This category rolls up one named declaration:

  • PENDING_FORMAL_VERIFICATION, the formal_verifier_status field in the manifest carries a deterministic placeholder emitted by the MockZkspAdapter today, not the verdict of a real Lean 4 theorem. The pipeline-determinism theorem the formal verifier is supposed to check has not yet been written. Determinism is currently established empirically (running the same inputs twice yields the same hash) rather than mathematically. To make the disclosure consistent, the artifact viewer at verdifax.com/app/artifact/?id=N renders the Formal Verifier Status row with a SCAFFOLD badge, and verdifax-verify --strict fails on the same flag.

Why we publish this page

Honesty is durable. A claim that is fully verifiable beats a claim that depends on a buyer's trust. When a buyer asks "is your hardware attestation real?", the right answer is not "yes" or "trust us." The right answer is "here is the audit bundle, here are the five named scaffolds, here is the closing path for each, here is the strict-mode verifier output." Auditors and regulators respect that answer in a way they do not respect marketing claims.

Closure path matters as much as the gap. Each gap above names the engineering phase that closes it, the documents that specify it, and the type of specialist required. That is structurally different from "we're working on it", it is a documented production roadmap that can itself be audited.

The system enforces its own honesty. The is_scaffold: true flag is emitted by the orchestrator code, not by marketing. The independent verifier surfaces it. The PDF audit report displays it. The five declarations above are exactly what an auditor sees in the JSON; they are not aspirational language, they are what the system says about itself today.

Reading scaffold flags in your bundle

When you receive a Verdifax audit bundle (via the artifacts endpoint or as a JSON download), look at these specific paths:

transcript.scaffold.is_scaffold
hardware_attestation.scaffold.is_scaffold
zksp_binding.scaffold.is_scaffold
pote_proof.scaffold.is_scaffold

Any value of true corresponds to one of the gaps above (with activated_by and note fields giving you the precise context). The pote_proof flag is a special case, see "Closed gaps" below, and now reads false on every production run anchored to Sigstore Rekor. When all four read false, every scaffold gap has closed and the bundle is fully cryptographically rooted.

For programmatic enforcement in CI:

verdifax-verify --strict --show-evidence-summary bundle.json

This exits non-zero if any scaffold flag is set, regardless of whether the rest of the bundle's hashes verify correctly. The --show-evidence-summary flag prints the maturity report and an explanatory verdict line, so a CI failure carries the reason inline. Use this combined form as the gate in high-trust environments.

Closed gaps

pote_proof.scaffold, closed 2026-05-28

The PoteProof artifact carried a scaffold flag in early builds because the orchestrator's transparency-log integration was not yet live. As of 2026-05-28 the Sigstore Rekor adapter has been running in production for some time, and the scaffold-flag rendering logic was reviewed against what the orchestrator actually emits. The conclusion: the activation condition ("future ledger integration with Sigstore/Rekor") had silently already been met. Every production run sealed against the real public log carries a Rekor log index, a signed checkpoint, a Rekor-attested integrated time, and a Merkle inclusion proof, i.e., the textbook material a transparency-log proof of temporal execution is made of.

The builder now clears pote_proof.scaffold.is_scaffold to false automatically when ledger_backend = "rekor" with a non-empty log entry id, and surfaces the temporal evidence (ledger_log_id, integrated_time, signed_entry_timestamp, ledger_checkpoint) directly on the PoteProof for reviewer visibility. Runs sealed in mock-ledger mode (dev/test deployments) still carry the scaffold flag with an updated note that's accurate for those runs.

Engineering record: Task #214 in the project tracker.

When this page changes

Each time a scaffold gap closes, i.e., the orchestrator code is updated to emit is_scaffold: false for an artifact that used to scaffold, a new entry will be added to Closed gaps above with the date, release version, and a link to the engineering record that activated it.

Until that happens for any given gap, you should assume the gap is open and the bundle's strict-mode verification will fail.