Proprietary specification · AI agent trust

Every agent action, provable.

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.

SignaturesEd25519 + ML-DSA-65 / 87
Canonical formRFC 8785
AnchorsPublic-chain anchoring
StatusStaging · release candidate 4
SCROLL
01 The problem

AI agents now book, buy, write and deploy. Almost none of it can be proven afterwards. R-Series makes the proof part of the action.

02 How a receipt is made

Five steps, every time an agent acts.

Receipt pipeline01 / 05
01 · INTENT

The action is declared before it runs.

Who is acting, for whom, on what, and under which policy. Nothing executes without an attributable intent, and the intent fields travel into every receipt.

02 · CANONICAL BYTES

One exact byte form, then a hash.

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

03 · HYBRID SIGNATURE

Two signatures. Both must hold.

Ed25519 for today, ML-DSA-65 or ML-DSA-87 for the quantum era. In the hybrid suite, a missing, stripped or invalid leg fails verification. No "either one will do".

04 · LINEAGE

Each receipt points to the one before.

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

05 · ANCHOR

The root is written to a public chain.

Roots are written to a public chain, so anyone can check inclusion without trusting DCS. Anchoring for the current release is in development.

02b The whole system

From a request to a proof anyone can check.

R-Series workflow01 / 08
STEP 1 · INTENT

A person or system asks an agent to act.

The request becomes a signed intent: who asked, for whom, what for, under which policy.

STEP 2 · POLICY

The policy decides before anything runs.

Limits, approvals and delegated authority are checked. Money and autonomy stay off until a human opens the gate.

STEP 3 · ACTION

The agent does the work.

A tool call, a model run, a file write, a payment. Through Connector OS or the MCP shim, nothing about the agent changes.

STEP 4 · RECEIPT

The action becomes a receipt.

Eleven fields, canonicalised with RFC 8785, hashed with SHA-256.

STEP 5 · SIGNATURE

Signed twice: Ed25519 and ML-DSA-65 or -87.

Both legs are required. A stripped or invalid leg is a rejection.

STEP 6 · LINEAGE

Linked to everything before it.

The receipt names its parent and joins a Merkle tree and a log.

STEP 7 · ANCHOR

The root goes on a public chain.

Roots are written to a public chain. Anchoring for the current release is in development.

STEP 8 · VERIFY

Anyone checks it, offline.

An auditor, a regulator or a counterparty checks the signature, the hash and the inclusion offline, without asking DCS.

03 Quantum

Receipts signed today must still verify in 2040.

Data recorded now can be decrypted later. Signatures made now can be forged later. New R-Series receipts are designed hybrid from day one: a classical signature and a lattice-based post-quantum signature. The hybrid issuer is release candidate 4, running on staging.

THREAT

Harvest now, decrypt later

Ciphertext captured today waits for a quantum computer.

THREAT

Forge later

Classical signatures on long-lived records become forgeable.

ANSWER

Hybrid by default

Ed25519 and ML-DSA-65, fail-closed. Staging · release candidate 4

ANSWER

Crypto agility

A suite registry so old receipts stay valid while new ones move on.

04 Evidence, not adjectives

Honest status, in three words.

Every item on this site carries one of four labels: In production Staging In development Planned. Verification of receipts from our own product, Website Maker, is in production. The R-Series engine with its hybrid post-quantum signatures is release candidate 4, running on staging, not in production, and nothing is presented as independently assured until an outside party signs it off.

Where we are: under audit, ahead of independent certification. The fourth release-candidate tag is signed by the founder. The first block of certification checks has been confirmed on an independent machine, and the last part of the candidate is under its final independent audit. ML-DSA-87 will follow as a future opt-in profile.

05 The stack

Fifteen layers, one receipt underneath.

05b Programmes

One engine, and the programmes built on it.

The receipt engine is the trust boundary. Everything else consumes it, and each programme is tracked against its own gates.

05b Two hybrid strengths

ML-DSA-65 or ML-DSA-87. You choose.

DEFAULT

Ed25519 + ML-DSA-65

The balance of size and strength for most records: enterprise, finance, government.

In development

DEFENCE PROFILE

Ed25519 + ML-DSA-87

The highest ML-DSA security level, the one CNSA 2.0 names for national-security systems. For defence and strategic programmes.

In development

Both are hybrid: a forger must break the classical and the post-quantum signature at once. Choose one per system, run both side by side, or move from one to the other with signed migration evidence.

06 Where it matters

Built for places where "trust us" is not an answer.

07 First proof

Proven on its makers first.

The organisation that built R-Series runs on it. One human directs a fleet of AI lanes; their actions are signed and logged, with money and autonomy kept off behind a human approval gate.

In development

Next

See R-Series on your own systems.

A 45-minute technical briefing: the receipt format, the hybrid suite, and what a migration looks like for your estate.

Request a briefingRead the developer guide