VerdifaX

Scaffold gaps

Verdifax is honest about what it cannot yet do. The audit bundle carries three open scaffold flags on every run today, one per artifact that returns a placeholder or a declaration rather than a real cryptographic value or measurement. Runs on the hosted service carry a fourth flag, hardware attestation, because the hosted service runs without an attestation agent; deployments with an AMD SEV-SNP attestation agent bind a verified quote and clear that flag. Proof of temporal execution has graduated and is real on every Rekor-anchored run (see "Closed gaps" below). Each flag is disclosed in the audit bundle itself: the scaffolded section carries is_scaffold: true, an activated_by note naming what clears it, and a plain-language note, all emitted by the orchestrator code and tracked in the project roadmap with a documented closing path. The hardware-attestation section also lists its tier4_blockers. 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: runs sealed with a SEV-SNP attestation agent carry a real AMD hardware quote bound inside the run's execution record (see "Closed gaps" below). The hosted api.verdifax.com runs without an agent today, so its runs still carry the honest scaffold; a standing evaluation endpoint, attested.verdifax.com, runs the in-guest configuration on request (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 no value in the bundle carries a scaffold flag. Today every run carries scaffold flags, so --strict fails every run by design until the open categories below close.

The three 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. Timing declarations, leakage_bundle.scaffold

Why it's scaffold today. The leakage bundle's two booleans, constant-time compliance and no observed timing variance, are design declarations of the deterministic scheduler, not per-run measurements. Per-stage wall-clock timing is measured on every run and sealed separately in the runtime timing section, but these booleans are not derived from it.

What activates the real value. The flag clears when the constant-time booleans are derived from per-run measurement instead of declared.

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

What the bundle discloses: the transcript section's transcript_hash is a domain-tagged SHA-256 over the execution record's proof.v1 hash, not a real STARK / PLONK / Groth16 proof. The hash is byte-stable and replayable, but it proves nothing about the computation beyond what the record's other hashes already bind. The section's activated_by note reads "phase 6 (real ZK prover, winterfell)".

3. 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 referencing that development: repository, pinned commit, toolchain, theorem list, and audited axiom footprint. The record is self-consistent (its hash recomputes from its contents) and names its run (it embeds the bundle's manifest hash); verdifax-verify checks both and reports the binding under --show-evidence-summary. On successful runs sealed from run 238 on, the complete-record anchor binds the record to the public log. On earlier records it is not bound to the public log, so a party able to rewrite the whole bundle could change it and recompute its hash. 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). In the code, the section's activated_by note ties the flag to the real winterfell prover; gating the success token on the pinned Lean artifact is further roadmap work.

What the bundle discloses: the formal_verifier_status field in the manifest carries the deterministic value SCAFFOLD_R1CS_HASH_FACADE emitted by the MockZkspAdapter today, not a verdict computed by invoking the Lean development at runtime. The theorems themselves now exist and are referenced in every new bundle via the formal_verification record; determinism is established both empirically (the same manifest fields always recompute to the 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 scaffold notes 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
leakage_bundle.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 five 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). The other three (transcript, leakage_bundle, zksp_binding) read true on every run today. When all five 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. Since 2026-10-02 the quote is taken before the run's execution record is built. Its guest-controlled 64-byte report_data field must equal sha512("verdifax.sevsnp.report_data.prerecord.v1:" + input_hash + ":" + transport_hash + ":" + execution_control_hash + ":" + program_hash + ":" + kernel_output_ids joined by ":"), every other field of the record, and the record's hardware field is then the SHA-256 of the report, so the quote and the record each bind the other. Runs sealed before 2026-10-02 used the post-run binding sha512("verdifax.sevsnp.report_data.v1:" + envelope_hash + ":" + aer_hash); the verifier checks each run under the binding it was sealed with.

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. Where the workload ran is recorded per run. In the attestation-service pattern the quote comes from a separate confidential instance and the artifact declares ORCHESTRATOR_WORKLOAD_NOT_IN_ENCLAVE. When the orchestrator runs inside the attested guest, the artifact names it the execution environment and declares COLOCATION_OPERATOR_DECLARED: the quote proves the guest and its launch measurement, while the launch measurement covers the guest firmware rather than the orchestrator binary, so colocation is the operator's statement. In-guest execution was demonstrated on 2026-10-03; that run's sealed bundle is public at https://verdifax.com/evidence/hardware-run-2026-10/runs/3/bundle.json. Since 2026-10-05 a standing evaluation endpoint, attested.verdifax.com, runs the same in-guest configuration: it is kept offline between evaluations, brought online on request, and every record it seals verifies with the public verifier. Additional platforms (TPM 2.0, Nitro Enclaves) remain roadmap work (ADDITIONAL_PLATFORMS_ON_ROADMAP).

Fail-closed, and per-run honesty. With an agent configured, a quote that cannot be obtained or verified halts the run with no record, and the orchestrator refuses to start if its agent does not return a verified quote at boot, so a broken agent is a failed deploy rather than a silent downgrade. Deployments with no agent configured, which includes the hosted service today, 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.

Pipeline stages graduated 2026-10-02

These were never bundle scaffold flags, but the audit PDF's maturity table rated them below REAL, and they are now real in every run:

  • The execution record is computed with the aer.v1 formula from Verdifax's allowed US patent application, with a proof.v1 proof, every preimage field disclosed in the bundle's execution_record section, and both recomputed by verdifax-verify since v0.5.0.
  • Transport fixes each route's order with persisted sequential positions and refuses reordering, duplicates and retry mutation.
  • Kernels: the six output identifiers come from the kernels themselves; the maturity table rates a run REAL only when its sealed fields show it.
  • Program authorization: programs can be registered with a hardware class and allowed routes, and with enforcement on, an unregistered or unsatisfiable program is refused before transport.

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.