Roadmap

What ships today.
What's next.
What needs specialists.

Most vendors hide their roadmaps. Verdifax publishes because every claim should be auditable , today by running the open verifier, and tomorrow by the same standard once specialists land.

▣ Shipped

Shipped today

Built and in use today: the hosted API at api.verdifax.com, the customer portal, the open-source verifier and the public Lean proofs. Each card states its own scope, including what the hosted API does not run.

SHIPPED

§0 Deterministic Attestation Contract

Sealed sections hash as SHA-256 over compact JSON of their fields in a fixed order; the manifest hash is SHA-256 over the sealed manifest field values joined with ".". Identical canonical field sets hash identically, byte-for-byte, and replaying the same inputs under a pinned clock and nonce, with the public-log stage held fixed, reproduces the same manifest hash. Cross-language test vectors verified by parallel Go and Python implementations.

Fixed-order JSONGo + Python verified
SHIPPED

Core deterministic pipeline (DOG · DTL · DKEC · AER)

Stages 1-4: Deterministic Oracle Gateway, Transport Layer, Kernel Execution Controller, Attestation Execution Record. Every external input is canonically encoded, sequenced, dispatched, and aggregated into a sealed record; on leaf v5 records the stage outputs are among the 33 pre-anchor values bound to the public-log entry.

4 stagesManifest sealing
SHIPPEDLIVE

AIVP, Live AI Verification Protocol

AI Verification Protocol governance running against the live Anthropic Claude API. When a governed run includes AI output text, that text is sent to the Claude API for a governance review, and a hash of the text and the review's PIA hash are sealed into the manifest. Adapter ID surfaced honestly in every audit PDF.

Live Claude APIPIA hashed
SHIPPED

PEPG + MCD, Pre-execution policy gating

Signed PSL policies evaluated before any kernel runs. Issues either a sealed AllowToken (admit) or a sealed DenyReceipt (reject). Threshold-signed policy support; Malicious Code Defense (MCD) scans every request payload for code-attack signatures during evaluation. Since orchestrator 564f1d4 (October 19, 2026 UTC), each allowed run's public bundle seals the gate's decision in epa.policy_gate (the policy's identifier, name, version and hash, the fired rule and the reason code); since v0.15.0 the verifier prints it and, with --policy, checks a held policy document against it. The policy hash covers the document's schema, identifier, name, version, effective time and default effect; each rule's identifier, effect, subject, verb, object, conditions and reason code; the signature policy; each signer's identity (signer identifier, key algorithm and key fingerprint); and the required attested fields, required outcome fields and profile tag. It excludes metadata, tags, rule names, priority, signature bytes and signing timestamps, and fields the policy format does not define. Priority is reserved and the evaluator does not read it. From verifier v0.15.1 and orchestrator d55a2cc (October 19, 2026 UTC) on, a policy document that sets a non-zero priority, names a key the policy format does not define, or spells a key in a different letter case is refused by both the server's policy reader and verdifax-verify --policy.

PSLThreshold signing
SHIPPED

CCV + MACC, Runtime budget enforcement

Per-run and cumulative (per API key) budget checks on the consumption each request declares. A run that would exceed its budget is halted after kernel execution; the checks support token, cost and time limits, and the hosted API sets token budgets. Sealed CCVHaltReceipt or MACCHaltReceipt preserves the original AllowToken hash; the CCV receipt also carries the partial-execution hash.

Token budgetsSealed halt receipts
SHIPPED

NREP, actor signing

Every execution carries an Ed25519 actor signature over the run's identifiers, stored in the record with the public key and the signed clock. Since orchestrator and verifier v0.8.x (2026-10-15), the actor section and the scaffold flags are SEALED into the public-log anchor: the version-3 ledger leaf embeds digests of both, recomputed by the verifier from the record's own contents, so replacing the actor or clearing a placeholder flag breaks the anchored leaf. The verifier reports a valid signature as CONSISTENT, and as SEALED only when the anchored leaf covers the actor section (a version-3 leaf embeds its digest; since verifier v0.14.6, a version-5 to version-7 leaf counts by binding the pre-anchor table, which carries the actor id, public key, signature and signing time) and, since verifier v0.14.7, the public-log entry itself matches (inclusion proof, signed checkpoint, and the entry naming this record's leaf) and was signed by a published Verdifax log-signing key; deliberately never as verified identity: the key is still the one the record supplies, and pinning keys against a registry is the queued step that upgrades sealed consistency to identity. Unanchored records can no longer share a verdict with anchored ones: the verifier fails them by default, the answer to a demonstrated downgrade edit. Records sealed before these changes are reported honestly as predating each protection. Today Verdifax generates and holds each API key's signing key in its database, so a signature shows that the Verdifax server signed with that key, not that the customer did.

Ed25519Actor signing
SHIPPED

CRES, Cryptographic Record Erasure

AES-256-GCM envelope encryption with per-record DEKs; erasure destroys the DEK and issues a sealed deletion receipt. 17 unit tests. Not yet wired into run sealing: no stored field is encrypted under these keys today, so an erase does not remove any stored content.

Per-record DEKsNot yet wired into sealing
SHIPPED

CES + LTC, Compliance & legal evidence

Control & Enforcement System applies classification + retention to every run. Legal Translation Compiler maps manifest fields to a LegalEvidenceArtifact with US, EU, and UK evidence sections. Admissibility remains a matter for the court, and the records carry no eIDAS qualified-seal presumption.

USEUUK
SHIPPEDNEW

Semantic Attestation Policy Profiles

Admission-time gap check: a policy can require specific AttestedContext fields before a run is admitted, and a missing field produces a sealed AttestationGapReceipt. The check is in the orchestrator, and four starter profile definitions are in code (healthcare, financial governance, internal audit, GDPR-aligned), but they are not yet wired into the hosted API: its baseline policy requires no attested fields, so the hosted API does not produce attestation-gap outcomes today.

4 starter profiles in codeNot yet wired into hosted API
SHIPPEDLIVE

Sigstore Rekor integration

Every successful run is committed as a hashedrekord entry on rekor.sigstore.dev, a public transparency log that Verdifax does not operate. Production mode is live; the audit PDF discloses ledger mode honestly on every run, and the orchestrator halts hard on Rekor unreachability (no silent fallback to mock). From run 238 on (2026-10-16, 17:06 UTC) each successful run also gets a second entry that binds the complete sealed record, and from run 239 on the first entry states that the second is required, so deleting it fails verification; since v0.12.1 the verifier checks both entries, binds each anchor to its log entry, checks who logged each entry and when, and refuses bundles whose JSON keys are ambiguous across readers. Since verifier 0.12.0, a public-log entry counts only if it is signed with a published Verdifax log-signing key and the timestamp the log signs for it verifies, so a rewritten record that anyone else logs as a new entry fails. Verdifax holds that key. From run 240 on, each record seals a 600-second anchoring window, so a later re-log, even by Verdifax, fails or must carry a new sealed date; earlier records show their authenticated anchoring time but cannot fail on it.

SigstoreProduction modeRFC 6962 Merkle
SHIPPED

Audit PDF + open-source verifier + SDKs

Receipt-style legal evidence document for every run. Open-source verdifax-verify CLI recomputes every section hash, the bundle hash and the anchored leaves offline. Four SDK clients (Python, Go, Node, R); the Python, Go and Node clients also wrap server-side run verification, which the R client does not yet include.

Open-source verifierPython · Go · Node · R SDKs
SHIPPED

CRES master key custody (AWS KMS)

The CRES master encryption key lives inside AWS KMS (us-east-1). Migration from Fly secret store completed. Because CRES encryption is not yet wired into run sealing, this key protects no stored field today, and customer signing keys remain in the service database.

AWS KMSus-east-1
SHIPPED

Public-log signing key custody (AWS KMS)

Since 15:59:19 UTC on October 24, 2026, every public-log entry the hosted API makes is signed by Verdifax log-signing key 3, an ECC P-256 key in AWS KMS (us-east-2) whose private key never leaves KMS: the server asks KMS to sign each entry. Verifier v0.17.0 pins key 3 for entries logged from that moment on and accepts key 1, the earlier key that was a file on the server volume, only for entries logged before it.

AWS KMSus-east-2Verifier v0.17.0
SHIPPED

Reproducible Docker TCU layer

Every base image SHA-pinned. Cargo with --locked, Go with -trimpath. SOURCE_DATE_EPOCH plumbed through Rust + Go stages. Standing CI 'double-build verification' gate. A reproducer recipe is written but kept in the private orchestrator repository, not yet published, and the image is private.

SHA pinningReproducible buildsCloses 80% of TCU
SHIPPEDLIVE

Trade reconciliation batch attestation

POST /execute/batch attests N rows in a single round-trip with per-row error handling. Each successful, refused or halted row is stored the moment it is decided, so its record carries its own run number, and is then anchored on the public log; only rows that fail with a stage error are stored together at the end; such a row has no record to anchor, but a row that failed at the public-log stage may have left an entry the server never received an answer for, which matches no record. From orchestrator d55a2cc (October 19, 2026 UTC) on, the server looks a late or duplicate entry up by its leaf hash and continues. Successful batch rows sealed before run 248 state run 0 (run_id 0); from run 248 on they carry their own run number (run 247 is a refused receipt). Up to 1,000 rows per call, sealed end to end against production. Real-time / microsecond HFT remains a specialist build, tracked on the specialist roadmap below.

POST /execute/batch1,000 rows per callHalt receipts
SHIPPEDLIVE

Reproducible-research toolkit

Category 6 ReproducibilityContext is recorded in every audit bundle, sealed by its section hash and, on successful runs sealed from run 238 on, covered by the complete-record anchor on the public log: runtime version, pinned dependencies, git SHA, declared random seeds, platform descriptor, optional container image hash. POST /execute/verify-determinism runs a payload twice and grounds the determinism flag on manifest-hash equality. Ships with Python (`pip install verdifax`) and R (`remotes::install_github("Verdifax/verdifax-sdk-r")`) wrapper SDKs, a Jupyter notebook, an R Markdown template, and the /research/ guide on docs.verdifax.com.

Python · R SDKsCat 6 audit recordDeterminism check
SHIPPEDNEW

Formal verification, Lean 4 proof development

The 12 headline theorems listed in each bundle's formal_verification record, machine-checked in Lean 4: determinism, injectivity (no two distinct field lists share an encoding, under the null-free field discipline the runtime enforces) and version binding of the canonical preimage encoder; the lifting of those guarantees to the hash layer under an explicit collision-freedom assumption; pipeline determinism, policy-gate soundness for completed and denied runs and budget-halt preservation over a model of all nine stages; manifest binding (equal sealed manifests force identical admitted inputs and outcomes); and an R1CS gadget-composition lemma. Kernel-verified on every commit by CI with a pinned toolchain and an axiom audit. These are theorems about a Lean model: proof that the model matches the production Go code remains on the specialist roadmap below.

Lean 412 headline theoremsCI kernel-checked
SHIPPEDLIVE

Trial keys and Stripe payment gating

API keys are issued in trial mode, capped at 5,000 runs per 30 days. An admin links a key to its Stripe customer; Stripe's signed invoice.paid webhook then promotes that key to production, and a deleted subscription returns it to trial. The webhook's signature is checked with the endpoint's signing secret; Verdifax holds no Stripe API key.

Trial quotaSigned Stripe webhookTier promotion
SHIPPEDNEW

Customer portal

Authenticated portal at verdifax.com/app: API-key login validated against the orchestrator, run history with search, full artifact viewer (every sealed hash, scaffold disclosures, Rekor anchor), audit-PDF download, and browser-based sample attestation. Key management (mint, scope, expiry, revoke) and access-request review are founder-only admin surfaces behind an additional access gate; customers have no self-service key tools. Access requests are approved by a human; an approved requester receives a one-time link by email, and their API key is minted when they open it.

API-key authArtifact viewerKey management
SHIPPEDNEW

Hardware attestation, first platform (AMD SEV-SNP)

When a SEV-SNP attestation agent is configured, every run takes a real AMD SEV-SNP attestation report BEFORE its execution record is built: the report's report_data is computed from every other field of the record, the orchestrator verifies the VLEK endorsement chain against AMD's pinned Milan root and the report's ECDSA P-384 signature, and the SHA-256 of the report becomes the record's hardware field, so the quote and the record each bind the other. A configured agent that fails halts the run, and the server refuses to start if the agent does not work. First produced 2026-07-17, bound to the run (the report was taken after the run and computed from its envelope and execution-record hashes); record-bound as described here since 2026-10-02. Demonstrated end to end on 2026-10-03 with the orchestrator running inside an AWS SEV-SNP guest (operator-declared colocation): the run's sealed bundle is public at verdifax.com/evidence/hardware-run-2026-10/runs/3/bundle.json and verifies offline with verdifax-verify, including the current v0.17.0. Honest scope: the hosted api.verdifax.com does not run on confidential hardware today, and its records say so per run. Additional platforms (TPM 2.0, Nitro Enclaves) are on the specialist roadmap.

AMD SEV-SNPRecord-bound quotePinned AMD root
SHIPPEDNEW

Execution record built with the patent application's formula (aer.v1)

Every run's attestation execution record is computed with the formula from Verdifax's allowed US patent application (Notice of Allowance, 2026-10-02): one prefix-isolated SHA-256 over the input, transport, execution control and program hashes, the six output identifiers at fixed positions, and the hardware field, plus a proof binding the record to its hardware field. Every preimage field is disclosed in the bundle, and verdifax-verify recomputes both offline (since v0.5.0).

aer.v1proof.v1Verifier since v0.5.0
SHIPPEDNEW

Ordered transport, program registry and real kernels

The transport stage fixes each route's order with persisted sequential positions and refuses reordering, duplicates and retry mutation under a hybrid logical clock. Programs can be registered as immutable records with a hardware class (SEV_SNP_VM, TPM2_PHYSICAL or NONE_DEVELOPMENT) and allowed routes; with enforcement on, a run must claim a registered record or it is refused before transport. Of the six output identifiers, the DSE, TOK and DSC slots are the kernels' own outputs; the NREP and DCAE slots are identity and closure commitments, and the AIVP slot holds a pending commitment that the governance PIA hash replaces only when the review releases the output.

Ordered transportProgram registryReal kernels

◌ Specialist track

Specialist roadmap

Real engineering, not marketing. Each item requires a specific specialist Verdifax doesn't yet have on the team. Listed publicly because honest sequencing matters.

Cryptography

SPECIALIST REQUIRED

Real ZK prover (winterfell STARK/FRI)

Replaces the deterministic R1CS hash facade with a real winterfell STARK/FRI prover. R1CS → AIR adapter, multi-prover equivalence, cross-toolchain reproducibility CI.

Specialist
ZK cryptographer
Timeline
3-6 months
SPECIALIST REQUIRED

Missing ZKSP proof steps

Transcript proof, hardware attestation proof, leakage upper bound. Each step requires defining a proof property mathematically and proving it preserves chain security.

Specialist
ZK cryptographer (plus hardware crypto for the attestation step)
Timeline
6-12 months
SPECIALIST REQUIRED

Formal verification: model-to-implementation fidelity

The Lean 4 development is shipped and public (github.com/Verdifax/lean-verdifax): the full tree, the pipeline_determinism and manifest_binding theorems over a model of all nine stages, and axiom-audit CI that rejects sorry and non-constructive axioms on every commit. What remains is the deepest step: machine-checked proof that the Lean model faithfully corresponds to the production Go and Rust implementations at the byte level (verified extraction or refinement proofs), so the theorems transfer from the model to the running code itself.

Specialist
Formal methods engineer (Lean 4, verified extraction)
Timeline
6-12 months
SPECIALIST REQUIRED

DEROT, Decentralized Root of Trust

3-of-5 threshold MPC quorum producing quorum-attested authorization. Threshold cryptography (BLS or Schnorr-based) and TEE-attested coordinator nodes.

Specialist
Threshold cryptographer
Timeline
3-6 months

Hardware

SPECIALIST REQUIRED

HRE, Hardware Root Engine multi-platform

Extends the shipped AMD SEV-SNP platform (see Shipped above) to TPM 2.0 and Nitro Enclaves, runs the hosted service itself on confidential-compute infrastructure (in-guest execution was demonstrated in a single run on 2026-10-03), and binds the orchestrator binary into the measured launch so colocation is proven by the quote rather than declared by the operator. Each platform has its own attestation primitives, certificate chains, and register semantics.

Specialist
Hardware engineer (secure-enclave)
Timeline
2-3 months

Distributed Systems

SPECIALIST REQUIRED

Spine, Network Determinism

Deterministic networking layer with zoned routing and Byzantine Fault Containment. Network-level determinism (no retries, no reordering across nodes) is research-grade work.

Specialist
Distributed systems engineer (networking + BFT)
Timeline
6+ months
SPECIALIST REQUIRED

Native Verdifax BFT Ledger

Bespoke 21-node Byzantine consensus implementing native Proof of Temporal Execution. Long-term replacement for the Sigstore dependency. Until it ships, runs anchor on Sigstore Rekor.

Specialist
Distributed systems engineer (BFT consensus)
Timeline
12+ months

Capital Markets

SPECIALIST REQUIRED

HFT-grade in-process attestation

Real-time / microsecond trading attestation. Replaces the per-decision REST round-trip with an in-process attestation library (Go / Rust / C bindings) that seals each decision locally, batches sealed records into a periodic uplink to the Verdifax orchestrator, and produces the same audit bundle shape as the live REST path. Unblocks the high-frequency trading TAM, which the current REST path is not built for: every decision is its own governed run, and the batch endpoint, which takes up to 1,000 rows per request, runs and anchors them on the public log one at a time. REST throughput has not been load-tested.

Specialist
Performance / systems engineer (low-latency cryptography)
Timeline
3-6 months

Sustainability

SPECIALIST REQUIRED

Full CSRD / SEC Climate enterprise reporting

Multi-tier supply-chain carbon attestation across Scope 1, 2, and 3.1-3.15 with LCA database integrations (ecoinvent, GaBi, GHG Protocol product factor sets). TCFD and SEC Climate Rule reporting templates, supplier attribution graphs, automated emission-factor version pinning. Promotes ESG carbon attestation from POC scope to enterprise-deployable.

Specialist
Sustainability data engineer + LCA partnership
Timeline
6-12 months

Industrial Provenance

SPECIALIST REQUIRED

Vehicle lifecycle + EU Battery Passport attestation

VIN-anchored or battery-anchored event chains: manufacturing genesis, ownership transfer, recall remediation, repair lineage, odometer attestations, and EV battery health under EU Battery Regulation 2023/1542 (digital passport mandate, Feb 2027 deadline for ≥2 kWh industrial / EV batteries). Verdifax's existing DOG truth admission, PEPG policy gates, NREP actor signing, and AER lineage primitives apply directly. What requires specialist work: OEM / insurer / DMV ecosystem integration, real-time telemetry ingestion at vehicle-fleet scale, and production-grade hardware attestation that an ECU actually emitted the signed telemetry.

Specialist
Automotive industry partnership + production-grade hardware attestation
Timeline
12+ months (paced to EU 2027 deadline)

System Maturity Disclosure

Three open scaffold categories, plus hardware on hosted runs, named explicitly in every audit bundle.

Every Verdifax audit bundle names its open scaffold categories in the orchestrator code, surfaces them in every audit PDF, and prints them via the independent verifier under verdifax-verify --show-evidence-summary. Three remain open on every run today, and a fourth, hardware attestation, is cleared only on runs sealed with the SEV-SNP attestation agent, so records from the hosted API carry four flags. The three:

  • Timing declarations (leakage_bundle.scaffold), flagged 2026-10-15: the constant-time booleans are design declarations of the deterministic scheduler, not per-run measurements. Real per-stage wall-clock timing IS now measured and bundle-sealed on every run; the flag clears when the declarations themselves are replaced by measurement.
  • ZK transcript (transcript.scaffold), activates when the winterfell AIR adapter ships and validates determinism across three Rust toolchains.
  • ZK proof binding (zksp_binding.scaffold), activates when the winterfell prover replaces the transitional R1CS hash facade with real STARK proof bytes.

Hardware attestation graduated from scaffold to real on its first platform. Runs sealed with an AMD SEV-SNP attestation agent carry a verified hardware quote bound inside the execution record (hardware_attestation.attestation_mode = "sev_snp") with the scaffold flag cleared; the quote, endorsement certificate, and AMD chain are embedded for offline re-verification. Runs sealed without the attestation service still disclose the scaffold honestly: the flag reports what each individual run actually carried.

Formal verification is no longer a scaffold category. Every new audit bundle carries a formal_verification record naming the pinned Lean 4 proof development: repository, commit, toolchain, the kernel-checked theorem list (including manifest binding and pipeline determinism over the model), and the audited axiom footprint. The record is sealed by its section hash inside the bundle. On successful runs sealed from run 238 on, the complete-record anchor binds it to the public log; on earlier records only the run's formal-verification status is anchored, as one of the 33 pre-anchor values on leaf v5 records. The independent verifier recomputes its hash and checks it, and its scope statement says plainly that the theorems are about a model of the pipeline, with byte-format fidelity tracked on the specialist roadmap.

Full per-declaration detail, with the precise activation condition for each, is published at docs.verdifax.com/concepts/scaffold-gaps.

There is no silent fallback anywhere in the stack. Until orchestrator 1461f3a (October 19, 2026 UTC) there was one: when the live AI review's call to the Claude API failed, the review approved the text on a one-step trace of the text itself and the record still named the live adapter; the server now stops such a run at the review stage and seals no record. The verifier's --strict mode exits non-zero whenever any scaffold flag is set, so a strict pass means no value in the bundle carries a scaffold flag.

Want to discuss a roadmap item?

If a specific item is what your organization needs, whether it's shipping today or scheduled for the specialist roadmap, reach out. Pilot deployments help us prioritize what ships next.

Last updated: