Lucid Labs: the verification flywheel

01 — The flywheel

The verification flywheel.

A verification idea enters unproven and comes back proven, deployed, and standardized in the open. Four stations, one loop.

01

Experimentation

A multi-silicon research cluster with open, bare-metal access.

with VCF Explore the cluster →

02

Validation

Structured red-teaming with independent government teams.

Government red teams See the architecture →

03

Deployment

Shipped in NeoCloud, and published as open hardware.

NeoCloud Learn more ↓

04

Standards

What we learn in deployment becomes open standards the industry can adopt.

IETF · CCC · OCP Learn more ↓

Each idea moves through four stations: experiment, validate, deploy, standardize. What breaks under red-teaming feeds the next round of experiments, and what we learn running production clusters is what we propose as standards.

02 — Experimentation

An open research cluster with bare-metal access.

Hardware verification, side-channel analysis, TEE research, network inspection. This work needs physical, bare-metal access to datacenter-grade GPUs that no cloud provider offers. So Lucid built the hardware, and the independent Verifiable Compute Foundation governs the cluster and decides who accesses it.

Multi-silicon by design.

A dedicated bare-metal cluster spanning NVIDIA H100, H200, and B300 (Blackwell) and AMD Instinct MI355X, because real verification can't assume one vendor's chip.

Root of the machine.

BIOS/UEFI-level access, IPMI/BMC management, custom firmware, and NVIDIA Confidential Computing enabled: the access researchers need and clouds never grant.

Physical access, supervised.

Qualified researchers run real experiments on real silicon; Lucid runs the physical experimentation to spec.

Silicon in the cluster 1 / 4

NVIDIA H100

VCF

Verifiable Compute Foundation: the independent nonprofit that governs the research cluster and decides who accesses it. Lucid provides the hardware.

Explore the Experimentation Cluster → Run an experiment with us →

03 — Validation

Red-teamed by the people who didn't build it.

An architecture is only as good as the attacks it withstands. Before a government will adopt verifiable compute, its own agencies have to try to break it. So we run structured red-teaming programs with national security agencies and government research institutes, on a Builder-vs-Breaker model where the people trying to break it are never the people who built it.

Red-teamed for government adoption.

We run structured adversarial programs with national security agencies and government research institutes: the buyers who need the strongest possible proof before they trust verifiable compute.

Builder vs Breaker.

The teams trying to break the architecture are never the teams who built it. Independent red teams keep full technical authority over their own methodology and reporting.

Four capabilities under fire:

data residency, compute integrity, confidentiality, and AI Passports. Each one attacked, not asserted.

The output is public.

Fully documented, open-source, state-backed reference architectures, built to be demonstrated to policymakers and submitted to standards bodies.

Case study

An 18-month validation program with a government research institute, deploying our verification platform on real GPU infrastructure. The institute's cybersecurity group runs the adversarial testing and delivers formal vulnerability and penetration-test reports, retaining full technical authority over its own methodology.

Builder

Lucid deploys the verification platform on real GPU infrastructure.

Breaker

A government research institute's red teams attack it independently and report what breaks.

◉ Government red-team cluster

Explore the Red-Team Cluster →

04 — Deployment

Verification, in production and in the open.

The mechanisms that survive experimentation and validation don't stay in the lab. We ship them as part of our NeoCloud offering for government and enterprise clients (verifiable AI compute as a service), and we publish the reference architectures as open hardware so anyone can build, inspect, and certify their own.

Explore NeoCloud →

AI Passport Verified

Sovereign Agent

operated by Lucid Computing

sha256:7f3a…e9d1 Stockholm (Sweden) · AWS

Security & Compliance All 12 Passed

Is personal data protected? GDPR

Names, emails, and phone numbers are automatically removed before processing

GDPR mode active7,350 items redacted last month0 data leaks

Where is my data stored? Stockholm

All computation stays within your chosen geographic region

Stockholm (Sweden)No cross-border transfers

Is all my data encrypted? Intel TDX

AI runs inside encrypted memory that nobody, not even us, can access

TEE hardware attestedSLSA Level 3All memory encrypted

Is it safe from prompt attacks? Active

Every prompt is scanned before the AI sees it

385,410 prompts scanned2,012 blocked0 bypassed

Does it follow your rules? Enforced

Custom business rules are checked on every request and response

5 active rules100% compliance rate

Has the model been tampered with? Secure

The AI model is scanned for backdoors, trojans, and unauthorized modifications

5 integrity scans completed0 threats found

05 — Standards

Four questions. Four open standards.

Verifiable AI compute comes down to four questions that today are asserted but never proven. We turn each into evidence a regulator, a sovereign customer, or an auditor can independently verify, as open standards, so the whole industry can adopt them.

Where Published

Sovereignty Certificates

Where, physically, is the chip running this workload? Proven by ping-based location attestation: a bound derived from the speed of light, which no VPN can fake.

View the standard at sovcert.org →

Who In development

Verifiable Compute Identity

Who (and which agent) is using this chip, and did it stay in scope? Human identity-proofing, sanctions screening, and signed agent delegation chains.

What In development

Attestable Audit Profile

What can the deployed model actually do? Independent, cryptographically signed evaluations bound to a specific model checkpoint.

How In development

Verifiable Compute Accounting

How much compute, of what class, by whom? Hardware-rooted FLOP counting the operator can't reset.

Standards bodies & communities we engage with

A flywheel for verification technology.