VerdifaX

Scaffold gaps

Verdifax is honest about what it cannot yet do. The audit bundle carries two open scaffold flags today, one per artifact that returns a placeholder rather than a real cryptographic value, plus two categories that have graduated (hardware attestation and proof of temporal execution, both now real on production runs; see "Closed gaps" below). 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 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 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.
  • Before 2026-07-17, the hardware attestation step emitted a policy-scaffold record declaring the platform was not running on attested silicon. That category has since graduated: production runs sealed with the SEV-SNP attestation service now carry a real, run-bound AMD hardware quote (see "Closed gaps" below).

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 two open scaffold categories

The 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. 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.

2. ZK-state-prover binding, zksp_binding.scaffold

What is real today. The Lean 4 development tree is no longer empty. It carries a kernel-checked proof development (canonical-encoding determinism and injectivity, hash-layer lifting under an explicit collision-freedom assumption, policy-gate soundness, budget-halt token preservation, the manifest-binding theorem, the pipeline-determinism theorem over the model, and R1CS satisfiability lemmas), built by CI on every commit with an axiom audit that rejects unproven placeholders and ad-hoc axioms. Every new audit bundle carries a formal_verification record binding the run to that development: repository, pinned commit, toolchain, theorem list, and audited axiom footprint. The record is tamper-evident (its hash recomputes from its contents) and run-bound (it embeds the bundle's manifest hash); verdifax-verify checks both and reports the binding under --show-evidence-summary. The record's scope statement says plainly that the theorems are about a Lean model of the pipeline; byte-format fidelity of the model to the production Go implementation is roadmap work, disclosed as such.

Why the flag is still scaffold. Two things remain transitional. First, the manifest's formal_verifier_status success token is still emitted deterministically by the MockZkspAdapter at runtime, not derived by invoking the Lean development; the Rust adapter's frozen-theorem-signature check has not been wired to the populated tree. Second, the ZK proof bytes themselves are the transitional R1CS hash facade, not a real STARK proof (see category 2). The flag clears when the adapter's success token is gated on the pinned Lean artifact and the winterfell prover replaces the facade.

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 a verdict computed by invoking the Lean development at runtime. The theorems themselves now exist and are bound into every bundle via the formal_verification record; determinism is established both empirically (same inputs, same hash, checked in CI) and mathematically at the model level (pipeline_determinism, manifest_binding). What remains scaffold is the runtime linkage. 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, until that linkage is real.

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 is the verified quote you can re-check offline, here are the named scaffolds that remain, 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 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). Two of the four are per-run graduated categories, see "Closed gaps" below: pote_proof reads false on every production run anchored to Sigstore Rekor, and hardware_attestation reads false on every run sealed with a verified SEV-SNP quote (check hardware_attestation.attestation_mode = "sev_snp" and re-verify the embedded quote yourself). When all four read false, every scaffold gap has closed for that run 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

hardware_attestation.scaffold, graduated 2026-07-17

Hardware attestation is real on its first platform: AMD SEV-SNP. Runs sealed with the confidential-compute attestation service carry a genuine SEV-SNP attestation report with hardware_attestation.attestation_mode = "sev_snp" and the scaffold flag cleared. Before sealing, the orchestrator verifies three things and refuses the upgrade unless all pass:

  1. Certificate chain to the silicon vendor. The report's VLEK endorsement certificate must chain to AMD's Milan root of trust, which is pinned by SHA-256 fingerprint inside the orchestrator binary. A chain terminating anywhere else is rejected.
  2. Report signature. The report's ECDSA P-384 signature over its full body is verified against the endorsement key from raw bytes.
  3. Run binding. The report's guest-controlled 64-byte report_data field must equal sha512("verdifax.sevsnp.report_data.v1:" + envelope_hash + ":" + aer_hash) for this specific run, so a quote can never be replayed against a different audit record.

The full report, endorsement certificate, and AMD chain are embedded in the bundle (quote_b64, vlek_cert_pem, cert_chain_pem), so any third party can re-run all three checks offline, forever, without trusting Verdifax. The audit PDF renders a dedicated "Hardware Attestation (AMD SEV-SNP)" section with the launch measurement, TCB values, pinned root fingerprint, and binding recipe.

Honest scope, stated in the artifact itself: this is an attestation-service pattern. It proves genuine AMD SEV-SNP hardware produced a report bound to this run's identity; it does not prove the orchestrator workload executed inside that enclave. That stronger property, along with additional platforms (TPM 2.0, Nitro Enclaves), is disclosed roadmap work carried in the artifact's remaining declarations (ORCHESTRATOR_WORKLOAD_NOT_IN_ENCLAVE, ADDITIONAL_PLATFORMS_ON_ROADMAP).

Per-run honesty, like PoTE below: runs sealed without the attestation service (for example, when the confidential-compute instance is offline) still emit the policy-scaffold record with is_scaffold: true and the original three declarations (REAL_TEE_QUOTE_NOT_BOUND, PLATFORM_CERTIFICATE_CHAIN_NOT_VERIFIED, HARDWARE_BOUND_MODE_NOT_ENABLED_CURRENT_HORIZON). The flag reports what each individual run actually carried; a failed or absent quote can never masquerade as a verified one.

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.