Skip to content
DCSAITechnologies
Talk to us
In testingTrust Systems

R-SeriesTrust infrastructure for AI agents

Every agent action, provable.

Visit dcslabs.aiTalk to us

Release candidate 4 · staging · under audit

  • Platform & security teams
  • Regulators & auditors
  • AI developers
Built on R-Series rails. Every action produces a signed receipt and joins a tamper-evident, hash-chained lineage.About R-Series
Release candidate, on staging
RC4
Automated tests passed, 0 failed (internal run, 20 Oct 2026)
10,463
Deliberate defects caught by mutation testing
215 / 215
Signatures required: Ed25519 and ML-DSA-65
2 of 2
01 · The gap

AI agents now act. Almost none of it can be proven afterwards.

AI agents book, buy, write and deploy. When something goes wrong, the only record is usually a log in someone else’s database.

R-Series gives every action an AI agent takes a signed, chained receipt, designed for classical and post-quantum signatures together. Signature, hash and inclusion can be checked offline, by anyone, without asking DCS.

R-Series makes the proof part of the action.
02 · How a receipt is made

Five steps, every time an agent acts.

The same pipeline runs whether the action is a tool call, a model run, a file write or a payment.

  1. 01Intent

    The action is declared first

    Who is acting, for whom, on what, and under which policy. Nothing executes without an attributable intent.

  2. 02Canonical bytes

    One exact byte form, then a hash

    The body is canonicalised with RFC 8785, so two implementations produce the same bytes and the same SHA-256 digest.

  3. 03Hybrid signature

    Two signatures, both must hold

    Ed25519 for today, ML-DSA-65 for the quantum era. A missing, stripped or invalid leg fails verification.

  4. 04Lineage

    Each receipt points to the one before

    Receipts chain by content address and roll into Merkle trees. Change one byte and the root changes.

  5. 05Anchor

    The root goes on a public chain

    So anyone can check inclusion without trusting DCS. Anchoring for the current release is in development.

03 · The suite

Every algorithm, and what it is for.

Published standards only. Every receipt names its suite, so old receipts stay valid while new ones move on.

R-Series algorithm suite Hybrid · both legs required
Ed25519
Classical signature · RFC 8032Staging · RC4
ML-DSA-65
Post-quantum signature · FIPS 204Staging · RC4
ML-DSA-87
Defence profile · FIPS 204Opt-in, to follow
ML-KEM-768
Key encapsulation · FIPS 203In development
SLH-DSA
Hash-based signature · FIPS 205Planned
SHA-256
Digests, Merkle leaves and rootsStaging · RC4
RFC 8785
Canonical JSON for the receipt bodyStaging · RC4
Registry
Suite registry for crypto agilityIn development
04 · The stack

Fifteen layers, one receipt underneath.

Each layer carries one of four words: In production, Staging, In development or Planned.

  • Intent

    In production

  • Receipts

    Staging

  • Audit lineage

    In development

  • Zero-knowledge

    Planned

  • Federation

    In development

  • Reputation

    Planned

  • Sovereign memory

    In development

  • Governance

    In production

  • Quantum trust

    In development

  • Global trust

    In development

  • Confidential compute

    In development

  • Provenance fabric

    In production

  • Migration evidence

    In development

  • Key lifecycle

    In development

  • Long-horizon evidence

    In development

“In production” means in production for our own product, Website Maker. The receipt engine itself is release candidate 4, on staging.

05 · How we prove it

Nothing ships on our word alone.

Every release candidate goes through the same path before it counts.

  • Two model families review

    Two reviews from two different AI model families look for defects in every candidate.

  • Test first, then fix

    Each finding is reproduced by a failing test before any code changes, then proven fixed by that test.

  • Test the tests

    Deliberate defects are injected into our own code. A suite that misses them is not trusted.

  • Same verdict everywhere

    Verifiers in JavaScript, Python and Go must agree on every case. One difference is a defect.

  • A second machine re-runs

    The evidence is re-run on an independent machine before a decision is made.

  • A certifier signs

    The release decision is signed. Nothing is presented as independently assured until an outside party signs it off.

06 · Programmes

One engine, and the programmes built on it.

The receipt engine is the trust boundary. Every programme consumes it and is tracked against its own gates.

  • Programme 01

    PQC migration

    • Discover, plan, migrate, dual-run and verify
    • Every cryptographic change receipted
    • In development
  • Programme 02

    OT / IoT

    • DCS OT Gateway hardware and a physical bench
    • Receipts for every control action
    • In development
  • Programme 03

    Space and autonomy

    • Decisions made far away, verified on the ground
    • COSRYX and COSRYX · ORBIT
    • In development
  • Programme 04

    DCS Connector

    • Every action through every connector
    • DCS Connector produces facts; R-Series makes evidence
    • In development
  • Programme 05

    Our own lab

    • One human directs a fleet of AI lanes
    • Money and autonomy behind a human approval gate
    • In development
07 · Where it matters

Built for places where “trust us” is not an answer.

  • Financial services

    Agents that move money leave proof of every instruction, approval and settlement.

  • Government

    Sovereign, offline-verifiable records that outlive the systems that wrote them.

  • Critical infrastructure

    A staged, bench-first path to post-quantum trust, planned around uptime.

  • Defence

    Signed orders, bounded autonomy under jamming and checked firmware.

  • Aerospace & aviation

    Airworthiness and avionics records that last as long as the airframe.

  • AI & autonomous agents

    A signed receipt for every action an agent takes.

08 · Honest status

Where R-Series stands today.

From dcslabs.ai/r-series , checked 27 Oct 2026.

  1. In production

    Receipt verification for our own product, Website Maker.

  2. Staging

    Release candidate 4 is tagged, signed by the founder and running on staging. It is not in production.

  3. Under audit

    The first block of certification checks is confirmed on an independent machine; the last part of the candidate is under its final independent audit.

  4. Next

    Public-chain anchoring for the current release, then ML-DSA-87 as an opt-in defence profile.

No certification is held yet. R-Series is a proprietary specification; use requires a licence from DCS, and the full technical picture is shared under NDA.

Every feature, on screen

Inside R-Series

Pick a feature to see its screen, what it does, and how it works once you connect your own accounts and data. All values are demo data.

r-seriesIllustration · demo data
Receipts

Receipt · demo-agent / action 0042

Intentdemo-agent · write file for Example Org

Policydemo-policy-v1

Result hashSHA-256 · 9f3a…e21c

Canonical formRFC 8785

Signerdemo-issuer key

// demo: issue a receipt for an agent action
const r = await rseries.receipt({
  intent: { actor: "demo-agent", for: "Example Org", action: "file.write" },
  policy: "demo-policy-v1", result });

Signed receipts

Intent, policy, result hash and signer in one receipt — canonicalised with RFC 8785 and hashed with SHA-256.

Once you connect

Under licence, your agent runtime calls the R-Series engine for each action; the intent, policy, result hash and signer come back as one receipt.

See it

Inside R-Series

R-Series — screen 1
R-Series — screen 2
R-Series — screen 3
Works with

Part of one ecosystem

Start with R-Series.

Request early access, or talk to us about enterprise and sovereign deployment.

Visit dcslabs.aiAll products