About DCS Labs

00 Our story

A trust engine, proven on ourselves first.

DCS Labs started R-Series with a simple rule: never claim what cannot be reproduced. Every capability on this site is labelled with the strongest evidence behind it, and the things that depend on outsiders, such as audits and certifications, stay marked as pending until they happen.

We also decided to be our own first customer. The organisation that builds R-Series runs on it: one founder directing a fleet of AI lanes, each lane registered under a fleet root, signed actions going into a log, with money and autonomy kept behind a human approval gate.

R-Series is the trust spine under the wider DCS portfolio, with receipts built into most of its products.

1human deployer and approver

4status words on this site: in production, staging, in development, planned

1receipt format, checkable without asking DCS

0money or autonomy switched on without a human GO

01 How the fleet runs

One human. Many lanes. Every action on the record.

DCS fleet01 / 05

01 · DIRECT

One human sets the work.

The founder is the only deployer and approver. Lanes are given scoped tasks; none of them can widen their own authority.

02 · REGISTER

Every lane has an identity under a root.

Each AI lane is registered under a single fleet root with its own keys, so every action can be traced to the lane that took it.

03 · SIGN

Every action, signed and countersigned.

Lane actions are signed, then countersigned, so no single key can quietly vouch for its own work.

04 · LOG

Recorded in a log.

Signed actions go into a log. Making that log provably append-only is in development.

05 · GATE

Money and autonomy stay off.

Spending, production keys and unsupervised autonomy are switched off until the human opens the gate, and opening it is itself a signed receipt.

02 Why we exist

Agents will run more of the economy. Their actions should be provable.

We think trust in AI should come from evidence anyone can check, not from a vendor's reputation. So we publish the verifier and the vectors under licence, share the specification under NDA, and label every claim with how sure we are.

03 How the work is split

Builders build. Others check.

The founder's AI lanes write the receipts, issuers, anchors, verifiers and adapters. People who did not write the code certify, test, operate and harden it.

BUILD

Founder lanes

Every engine, receipt, verifier and adapter change, test-first, with internal AI-assisted audit passes after each candidate.

CERTIFY

Head of Cryptography

Rules on the cryptographic boundary and signs the certification record, never for work they built.

RE-RUN

Non-author re-runs

People who did not write the code re-run the evidence, so results do not rest on the builder's own runs.

HARDWARE

Hardware lead

Owns the OT bench and the reference gateway, where every OT/IoT claim is proved first.

OUR RELEASE RULE

Two model families, a clean fresh audit, a signed tag.

Every release candidate goes through audits by two independent AI model families before it is merged, and a fresh audit must find no high-severity issue. The founder signs each candidate tag. Building, certifying and re-running are three separate people.

Where we are: under audit, ahead of independent certification. The fourth candidate tag is signed; the first block of certification checks is confirmed on an independent machine.

04 Independence, honestly

What our own checks can and cannot prove.

We review our own work hard, with AI reviewers separate from the AI that builds. That is useful, but it is not independence, and we do not present it as such.

Independence comes from people and parties outside the build: a human cryptographer's sign-off, re-runs by people who did not write the code, an outside verifier and external review. Until those happen, this site says "in development".

05 The portfolio spine

One specification under many products.

DCS Verify

Trustless client-side receipt verification, certificates and registry.

In development

Website Maker

Reference integration: signed receipt chain, governance evidence and a release passport per build.

In production

Connector OS

Agents to business systems, a receipt on every action.

In development

PQC Migration

Discover, plan, migrate and prove an estate's move to post-quantum cryptography.

See the programme

OT / IoT

Gateways and firmware signing for plants and fleets, proved on a bench first.

See the programme

Space and autonomous systems

Trust for systems that run far from us: satellites, autonomous platforms and remote infrastructure.

See what we do there

Meet the people behind the receipts.

Forty-five minutes with an engineer: the format, the hybrid suite, and what a migration looks like for your estate.

Request a briefing

06 Questions

About DCS Labs.

Is the fleet real, or a demonstration?

It is how the company works. The lanes are registered and their actions are signed and logged internally; the money and autonomy gates are real and are kept closed.

Who decides what ships?

The founder approves every deployment. Certification of the cryptography is a separate role, so the person who approves a release is not the one who certifies its cryptography.

Why label so much as "in development"?

Because the alternative is to round up. Every item carries an honest label: in production, staging, in development or planned.

We run on whatwe build.