Platform overview

The trust layer under your agents.

R-Series does not replace your models, tools or clouds. It sits underneath them and turns every action into evidence: who asked, what ran, what it cost, what came back, and who signed it.

Anatomy of a receiptAll fifteen layers
LayersR+1 to R+15
Signature suiteEd25519 + ML-DSA-65
StatusIn development
00 In one paragraph

What R-Series is, and what it is not.

R-Series is a proprietary specification and reference implementation for AI agent trust; use requires a licence from DCS; the public verifier and vectors are published under licence. It defines how every action an agent takes becomes a signed, chained, verifiable receipt, and it provides the layers around that receipt: intent, lineage, zero-knowledge proofs, federation, governance, hybrid post-quantum signatures, provenance, and now migration evidence, key lifecycle and long-horizon evidence.

It is not a model, an agent framework or a monitoring dashboard. It sits underneath those, so whichever models and tools you choose, the evidence of what they did has the same shape and the same guarantees.

DCS Labs runs its own organisation on it: one human directing a fleet of AI lanes whose actions are signed and logged.

01 What it does

Agents act. R-Series writes it down, signs it twice, links it to everything before, and lets anyone check.

02 Four jobs

One substrate, four jobs.

Attribute

Every action is tied to an intent, an agent identity and a policy before it runs.

In production

Prove

An 11-field receipt, canonicalised and hybrid-signed, for every action and resource touched.

Staging · release candidate 4

Link

Receipts chain by content address and roll up into Merkle roots written to a public chain.

In development

Verify

Anyone can check a receipt offline, in a browser, without asking DCS for permission.

In development

03 The receipt

Eleven fields that answer the auditor's questions.

Each field exists because someone, somewhere, will ask about it later.

Every receipt answers
Which action is this, and what came right before it?
What was done, and to what?
Which model and which vendor produced the result?
Who paid, and how was the call routed?
When, exactly?
What came back, without storing the content itself?
Who vouches for all of the above?
04 Where it sits

Between your agents and everything they touch.

Picture an operations floor of agents working across your systems. R-Series is the layer that turns each of their actions into a receipt, chains the receipts, and rolls the chain up into a root for public anchoring.

Agent operations floor01 / 04
01 · ACT

Agents work as they already do.

Each lane on the floor plans, calls tools and talks to models. Nothing about how it reasons or which model it uses has to change.

  • Tool calls, model calls, file writes, API fetches
  • One identity per lane, registered under a root
02 · ADAPT

Plug into what you already run.

Connector OS speaks to CRMs, ERPs, data lakes, mail and payment rails through protocol adapters. The MCP shim does the same for tool calls. Your systems do not change either.

03 · RECEIPT

Every hop is receipted and signed twice.

Each call through an adapter emits an R-Series receipt: canonical bytes, a SHA-256 digest, and both an Ed25519 and an ML-DSA-65 signature. Each receipt names its parent, so the receipts form a chain.

04 · GOVERN + ANCHOR

Policy before money moves. A root anyone can check.

Approvals and delegated authority are themselves signed. Spending and autonomy stay off until a human opens the gate. Receipts roll up into a Merkle root, ready for anchoring on a public chain.

05 The fifteen layers

Fifteen layers, one receipt underneath.

Every layer speaks the same receipt, on one engine underneath. Each layer is labelled with one of four words: in production, staging, in development, or planned.

One stack, fifteen layers.

Intent, receipts and lineage at the base; governance, post-quantum control and provenance in the middle; migration evidence, key lifecycle and long-horizon evidence on top.

LayerWhat it gives youState
R+1 IntentWhat the agent was asked, and allowed, to do, captured before it acts.In production
R+2 ReceiptsOne canonical, hybrid-signed receipt for every action.Staging · release candidate 4
R+3 Lineage + anchorReceipts chained by content address and rolled up for anchoring on a public ledger.In development
R+4 Zero-knowledgeProve a property of a receipt without revealing it.Planned
R+5 FederationReceipts issued by one organisation and honoured by another.In development
R+6 ReputationScores derived from receipts, outside the signed body.Planned
R+7 Sovereign memoryAgent memory sealed client-side, with provenance and erasure.In development
R+8 GovernanceApprovals and delegated authority as signed receipts.In production
R+9 Hybrid / PQ controlHybrid signatures, key custody and crypto agility under every layer.In development
R+10 InteropProfiles, encodings, vectors and verifiers for other implementers.In development
R+11 Confidential computeAttestation of what ran, and where.In development
R+12 ProvenanceOne passport for a release artefact's whole life.In production
R+13 Migration evidenceProof that cryptography changed, and how.In development
R+14 Key lifecycleWhich key was valid, when, and who said so.In development
R+15 Long-horizon evidenceReceipts that stay verifiable as algorithms age.In development

In production means running on our own product, Website Maker. Layer-by-layer detail is shared in a private briefing.

06 How we label progress

Three words, used the same way everywhere.

IN PRODUCTION

Running for real

Live on our own product today.

In production

IN DEVELOPMENT

Being built and checked

Code exists or is being written; it is not yet live.

In development

PLANNED

Designed, not started

On the plan, behind earlier work.

Planned

07 Principles

Rules we hold ourselves to.

01

Never rewrite history

Historical bytes are never re-signed to look current. Changes ship as new, versioned profiles.

02

Fail closed

A missing leg, a stripped signature or an unknown suite is a rejection, not a warning.

03

Say what is proven

In production, staging, in development and planned stay separate words. Nothing is called "compliant" because a receipt exists.

04

One engine does the crypto

Products call the S1 engine; they never carry their own cryptography. That keeps one place to review, certify and upgrade.

05

Hashes, not content

A receipt records the hash of what came back, not the data itself. Your data stays in your systems.

06

Humans hold the gates

Money, autonomy and production keys stay off until a named human approves. The approval is itself a receipt.

See a receipt checked, step by step.

Every check runs in your browser. Tamper with a field and watch it fail.

Open the verifier
08 Questions

About the platform.

Do we have to change our models or agent framework?

No. Receipts are produced at the boundary, through Connector OS, the MCP shim or the reference library.

Where is data stored?

Receipts hold hashes, not content. Your data stays in your systems; receipts and anchors can be stored where your policy requires.

Is it production-ready?

Receipt verification is in production on our own product. The newer engine and most layers are in development; the status for your use case is shared in a private briefing.

Why two signatures on every receipt?

Ed25519 is the classical signature everyone can verify today. ML-DSA-65 is the NIST post-quantum signature. A verifier requires both, so a receipt stays trustworthy if either family is ever broken.

What happens if an agent's key is compromised?

Keys are registered with epochs. R+14 (in development) records which key was valid when, so a verifier can reject receipts signed after a revocation and still judge earlier receipts against the record of that time.

Want the details for your sector? Book a briefing — we share the full design and a live demo in a private session.