S1 engine · S2 universal receipt · A7 transport

One engine.
One receipt.
Every product.

Every DCS product, from website building to business connectors, OT gateways and migration tooling, is built the same way. Each asks a single engine to issue and verify its evidence, and each speaks the same receipt format. No product hashes or signs anything itself.

The engine contractThe receipt format
S1 engineIn development
S2 universal receiptIn development
A7 transportIn development
SignaturesEd25519 + ML-DSA-65
01 Why one format

Evidence is only as strong as its weakest signer.

When products issue evidence in different shapes, with different code doing the signing, every extra signer is another place where a key can leak and another verifier to keep correct. It is also one more format an auditor has to learn.

So DCS settled on one receipt format for every product, and one engine underneath it that does all the cryptography. Every product reaches it through the same small set of calls.

The result: one verifier can check a payment refund, a grid event, an IoT reading and a key rotation. An auditor learns one format once.

02 The boundary

Product code never hashes or signs. It asks the engine.

ONE BOUNDARY

No cryptography in any DCS component

Consumers are consumers. The engine's verify() is the single trust boundary. Even the OT gateway holds its device key only through the engine's custody path.

FROZEN

The mathematics is not touched

The wrap adds interfaces around the engine's primitives. Any edit inside them that is not an import path or an adapter is forbidden, and must be reported rather than made.

Standing rule

BUILDER ≠ CERTIFIER

Whoever writes it does not certify it

The people who build the engine are not the people who sign off its cryptography, and a non-author re-runs the evidence.

In development

03 S1 · the engine contract

Five things the engine does for every product.

S1 engine01 / 05
01 · ISSUE

The engine builds and signs each receipt.

One exact byte form of the receipt is hashed and signed with both a classical and a post-quantum signature. Placeholder identities and malformed payloads are refused before anything is signed.

02 · VERIFY

Verification recomputes, never trusts.

The verifier rebuilds the bytes and checks both signatures. A missing or invalid signature fails. Whether a key was later revoked is reported separately, so history stays readable.

03 · CHAIN

The sequence is checked too.

Receipts link to the one before. A gap in a complete stream fails; a partial set is flagged, not failed.

04 · COMMIT

Proof of content, without the content.

Products hand over payloads and get back commitments. Only those go into the receipt, so a receipt can prove a payment response or a firmware image without containing it.

05 · REJECT

The attacks ship with the engine.

The engine defines the inputs every verifier must refuse: stripped, swapped or reordered signatures, and other known tricks.

04 Two implementations

A second verifier, and an honest note about independence.

The same receipt must check out identically in two independent implementations, in two languages. Today the engine and a second verifier agree on every test vector.

Agreement is not independence. Real independence comes from people who did not write the code: re-runs by non-authors, outside reviewers and an outside verifier. We treat those as steps still to take, not as things already done.

05 S2 · the universal receipt

A closed core, with profiles on top.

Universal receipt01 / 05
01 · CORE

A closed core, by design.

The receipt has a fixed core that refuses anything it does not know. Both signatures are required, and the algorithms are fixed by the format, not chosen by the product.

02 · FIELDS

The questions every receipt answers.

Who acted, the declared intent, what was done, under which rule, what came back, when, and what came before. Products never write the signed bytes themselves.

03 · SIGNATURES

Both signatures or reject.

A classical signature and a post-quantum signature over the same digest. A downgrade, a strip or a swap fails verification.

04 · PROFILE

A profile adds fields. It never changes the core.

Each product adds its own payload on top, under a documented schema, shared under NDA. A payload that fails its schema fails verification.

05 · MANY PROFILES

One core, many domains.

Migration plans, key rotations, grid events, agent actions, gateway readings and generation jobs all share the same core. A verifier written once checks all of them.

06 Profiles

Built-in profiles and the products that consume them.

Migration evidence, key lifecycle and long-term archives each have a built-in profile. Website Maker, Connector OS, the OT gateway and other DCS products each have a consumer profile on the same core. External profiles have their own namespace, governed by DCS. Website Maker receipts are in production; the other profiles are in development.

07 Registry and schema

The format is a file, not a promise.

SCHEMA

A written schema

The receipt and every profile are written down as a machine-readable schema, shared with licensees. The engine accepts nothing that is not in it.

In development

CORPUS

Vectors and mutants

Positive and negative cases, with mutation testing, so a second implementation can prove it agrees.

In development

CLOSED

Closed on purpose

Because the receipt refuses unknown fields, any new field is a new version. Old receipts are never changed: renew, don't extend.

In development

08 A7 · compact transport

Small links get small bytes. The signature stays the same.

Some links are too small or too intermittent for JSON: field gateways, constrained devices, remote assets. A7 carries the same receipt in a compact, deterministic binary form.

A7 is a wire encoding, not a second receipt format. A compact frame converts back to exactly the bytes that were signed, so there is still one thing being signed and one way to verify it.

09 Progress

In development, and labelled that way.

The engine, the universal receipt and the compact transport are in development. Receipt verification on our own product, Website Maker, is in production. Nothing here is presented as independently assured until an outside party signs it off. The detailed status is shared in a private briefing.

10 Questions

What people ask us.

What stops a product from adding its own field to the core?

The schema. The core refuses unknown fields. Profiles may only add fields in their own payload, and a payload that fails its profile schema fails verification.

Is dCBOR a second receipt format?

No. It is a transport encoding. The signature always covers the canonical JSON body. A dCBOR frame converts back to those exact bytes, so there is still one thing being signed.

Can today's verifier check a receipt issued under a future algorithm?

Not today. The format is closed on purpose. A new algorithm arrives as a new version, and signed renewals carry old receipts forward. Old receipts are never re-signed.

Is any of this live?

Receipt verification is in production on Website Maker. The engine, the universal format and the compact transport are in development.

Who signs off the cryptography?

An independent cryptographer signs it off, with a re-run by someone who did not write the code. After that come an external review and an independent verifier.

One engine to trust. One format to verify.

See how the same receipt carries an AI agent's actions through Connector OS.

Connector OS × R-SeriesHow verification works

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