Connector OS × R-Series · the complete trust layer

If it cannot leave a receipt, it does not happen.

Connector OS lets AI agents act in GitHub, Slack, Salesforce, Stripe and hundreds of other systems. R-Series turns every one of those actions into signed evidence. A company, its auditor or a regulator can check that evidence themselves, years later, with the platform switched off.

Follow one actionOpen a receipt
Core ruleNo cryptography in Connector OS
ReceiptOne per executed action
SignatureEd25519 + ML-DSA-65
StateIn development
Planned

How to read this page

This page describes the target state: every R-Series layer applied inside Connector OS. It is in development. A target description is not a current claim. Zero-knowledge proofs and hardware-attested execution in particular stay target-only.

01 The idea

The connectors are the reach. R-Series is the trust.

Any integration platform can connect an AI agent to Salesforce or Stripe. None of them can give a company proof: a record of what the agent did, who allowed it, under which rule, and what came back. That proof has to be something the company, its auditor or a regulator can check on their own. The platform must not be able to edit it quietly, and it must still hold up years later.

Connector OS is an integration and execution platform. It has connectors to business systems and an Operations Agent Layer that lets AI agents observe, diagnose, plan and act through those connectors. It adds policy, human approval and a governed execution engine.

R-Series is a layered standard for machine evidence. Every consequential machine action gets a signed receipt that anyone can verify. In the target state, the receipt sits in an append-only log that independent witnesses cosign, is anchored in time, and stays verifiable for decades without the vendor.

Together they are designed so that every action through every connector leaves a receipt. When a receipt cannot be produced, the action is refused.

02 The core rule

Connector OS produces facts. R-Series turns facts into evidence.

BOUNDARY

No cryptography in Connector OS

Connector OS never hashes, signs or verifies on its own. Every cryptographic step goes through the R-Series engine. The rule applies to every DCS product.

ONE TO ONE

One receipt per executed fact

After each action is executed and checked, Connector OS emits one structured fact. R-Series issues exactly one receipt for it under the Connector OS profile.

In development

PRECONDITION

No receipt, no write

If evidence cannot be produced, Connector OS performs no write actions. The contract for this is agreed between the two products.

Planned

NO ORPHANS

Durable pending receipt

Sometimes the provider executes but issuing the evidence is interrupted. In that case a durable pending obligation is recorded and completed later.

Planned

03 The execution path

One action, from request to receipt.

R-Series is not a log written at the end. It reaches into the path at four earlier points: intent at the request, policy and approval decisions, credentials and the execution environment. The evidence runs through the whole action.

Execution path01 / 08
01 · REQUEST

An agent or a user asks for something.

The request enters through the runtime on the customer's own connection. The Operations Agent Layer observes, diagnoses and plans. The declared intent is captured here, for example "reconcile last month's failed payments", and travels with the action.

  • R+1 Intent
02 · POLICY

A rule decides.

Policy permits, refuses or escalates. The decision is itself receipted. New policies run in shadow mode first, and that run is receipted too. Reliability scores derived from receipts can tighten policy for an unreliable agent or connector.

  • R+8 Governance · R+6 Reputation
03 · HUMAN APPROVAL

When required, a person says yes or no.

The request waits at the gate. Issuing, consuming and revoking an approval are governance receipts. So are engaging and lifting the kill switch. The final receipt carries a reference to the approval it relied on.

  • R+8 Governance
04 · OPS BROKER

Credentials are evidence, not configuration.

OAuth grants, token refresh, scope changes and revocation are all receipted under R-Series key lifecycle. Connector secrets and agent context are encrypted per tenant and per subject.

  • R+14 Key lifecycle · R+7 Sovereign memory
05 · EXECUTION ENGINE

The action runs in a known place, on known code.

Each connector version carries a signed passport: manifest, permissions, dependencies, cryptographic bill of materials and build provenance. In the target state the engine runs in an attested environment, and the attestation is referenced in each receipt.

  • R+12 Provenance · R+11 Confidential compute Planned
06 · PROVIDER API

The real system changes.

Platform-to-provider transport uses hybrid key exchange where the provider supports it. Any change to a connector produces transition receipts with the before and after state. That covers provider API versions, auth method, scopes and cryptography.

  • R+9 Hybrid / PQ · R+13 Migration evidence
07 · VERIFY · RECONCILE

Did it really happen?

The result is checked against the provider: object id, status, retries, rollback and reconciliation. Only then does Connector OS emit the EXEC-FACT. Its nine outcomes map onto the receipt's outcome. An unknown outcome is recorded as ambiguous, never as success.

  • R+2 Receipt (input)
08 · R-SERIES

The fact becomes evidence.

The fact emitter hands the fact to the evidence client. In the target state R-Series then computes the digest, applies the hybrid signature, records log inclusion, gets a witness cosignature and anchors the result. The receipt is returned and stored with the action.

  • R+2 · R+3 · R+5 · R+10 · R+15 (R+4 Planned)
Request (agent or user) → Runtime (customer connection) → Operations Agent Layer (observe · diagnose · plan) → Policy → Human approval (when required) → Ops Broker → Execution Engine → Provider API → Verification & reconciliation → EXEC-FACT → Fact emitter → Evidence client → R-Series: digest · hybrid signature · log inclusion · witness · anchor → Receipt returned and stored with the action.
04 Anatomy of a connector receipt

The why, the who, the rule and the result.

Receipt anatomy01 / 05
01 · CORE

Every receipt starts from the same core.

A Connector OS receipt is a universal receipt, the same format every DCS product uses. The envelope is closed: it refuses anything it does not know.

02 · FIELD GROUPS

Who, intent, what, rule, payload proof, outcome, time, chain.

Each group answers one question an auditor will ask. The payload is never stored raw. Only digests of the request and response go into the receipt, so a copy of the content can later be checked against it without the receipt exposing it.

03 · SIGNATURES

Two signatures, both required.

The receipt carries a classical Ed25519 signature and a post-quantum ML-DSA-65 signature over the same canonical bytes. If either leg is missing, stripped or swapped, verification fails.

04 · PROFILE

The connector profile clicks on.

The profile adds what is specific to a connector without touching the core: which connector and tool acted, and how the request, the response and the provider's own record tie together.

05 · ONE CORE

The same core serves every product.

The core that carries a Stripe refund also carries a grid event, an IoT gateway reading or a key rotation. One verifier checks them all.

Field groupWhat it holdsWhy it matters
WhoTenant, requesting agent or user, approving human, service identityAccountability for every actor, human or machine
IntentDeclared purpose of the request (R+1)Shows actions that do not match what was asked
WhatConnector, connector version, tool or action (e.g. Stripe · create refund)The exact operation, tied to a specific connector build
RulePolicy and decision, and the approval it relied onShows the action was permitted, and by what
Payload proofDigests of request and response, never the raw dataProves content without exposing it
OutcomeProvider object, status, retries, rollback, reconciliation resultTies the receipt to the real effect in the provider
TimeEvent time, receipt time, log-observed time, anchor timeNo single clock has to be trusted
ChainParent receipt, workflow, previous action in the same runReconstructs multi-step agent work end to end
CryptoKey and key epoch, algorithm epoch, hybrid signature, log inclusion proof, witness cosignatureIndependent, long-lived verification

The profile defaults to the confidential data class, and refuses a missing tenant and placeholder identities.

05 All fifteen layers

What each R-Series layer does inside Connector OS.

Each R-Series layer has a job inside Connector OS. This is the target design.

LayerIn Connector OS (target)What the customer gets
R+1 IntentEvery agent request carries a declared intent; each executed action is checked against it and the intent is signed into the receipt.Agents that drift from their task are visible; reviewers see the "why".
R+2 ReceiptOne signed receipt per executed fact, under the Connector OS profile.A tamper-evident record of every action across every connected system.
R+3 Lineage + anchorReceipts chained per workflow and per tenant; roots anchored to an external time source.Full reconstruction of multi-system runs; proof that nothing was inserted or removed.
R+4 Zero-knowledgeProperty proofs over a tenant's receipt set, e.g. "every CRM write last quarter had a human approval".Give auditors evidence without handing over records.
R+5 FederationReceipts countersigned by the customer's own node, a partner or an independent operator.No single party, including the platform, controls the record.
R+6 ReputationReliability scores for connectors and trust scores for agents, derived only from receipts.Policy tightens automatically; buyers see real track records.
R+7 Sovereign memoryAgent context and connector secrets encrypted per tenant and per subject; deleting a subject destroys its key.Right to erasure works while receipts stay valid.
R+8 GovernanceEvery policy decision, approval, rejection, escalation and kill-switch use is a receipt; shadow mode first.Proof of human oversight; evidence for "who allowed this".
R+9 Hybrid / PQAll receipts hybrid-signed; hybrid key exchange to providers where supported.Evidence that stays trustworthy as cryptography changes.
R+10 InteropJSON and CBOR, SCITT statements, SDKs, SIEM feed; verifiers in JavaScript and Python.Any team verifies in its own stack.
R+11 Confidential computeExecution engine and secret handling in an attested environment, referenced in each receipt.Proof of where and on what the action ran.
R+12 ProvenanceSigned passport per connector version: manifest, permissions, dependencies, CBOM, build provenance.Customers know exactly which connector code acted on their systems.
R+13 Migration evidenceEvery connector change produces change receipts with before/after state.No silent behaviour change.
R+14 Key lifecycleOAuth grant, refresh, scope change and revocation receipted; per-tenant signing keys with epochs.A verifiable history of who could access what, and when it stopped.
R+15 Long-horizon + witnessAppend-only log, signed checkpoints, independent witness, coverage attestation, scheduled renewal.Gaps are explicit; records stay verifiable for decades.
06 Behaviours that come from R-Series

Trust is a precondition, not an afterthought.

01

No receipt, no write

If evidence cannot be produced, write actions do not run.

Planned

02

Durable pending receipt

If the provider executed but issuing was interrupted, a durable obligation is completed later. No action is left without its proof.

Planned

03

Tamper rejection

Every verifier rejects altered evidence, or a receipt signed with the wrong environment key.

In development

04

Explicit gaps

When a connector, a provider or the log is down, a coverage receipt records the exact interval. A missing record is never mistaken for missing activity.

Planned

05

Offline verification

A customer checks any receipt with the public verifier and the issuer's published keys, even with the platform switched off.

In development

06

Replay-safe reconstruction

Any incident can be rebuilt from the receipt chain: request, intent, policy, approval, provider effect and reconciliation.

Planned

07 What it means for people

Users, auditors and regulators each get something different.

DEVELOPER

Connect once, evidenced always

Every call is evidenced automatically. Debugging starts from the exact chain of what the agent did.

SECURITY TEAM

Every machine action, every credential event

A verifiable record that is ready for the SIEM. It proves least privilege and revocation instead of asserting them.

OPERATIONS

Agents that can be trusted with writes

Every write is approved, recorded and reversible, so incidents can be explained in minutes.

LEADERSHIP · CFO

A defensible answer

To the question "what did our AI do with our money and our customers' data?"

THE COMPANY'S CUSTOMERS

Disputes resolved with proof

A refund, a data export or a record change can be shown exactly as it happened.

PRIVACY

Erasure that keeps the evidence

Destroying a subject's key makes their personal data unreadable. The receipts around it stay valid, and the erasure itself is receipted.

For auditors. Signed evidence replaces screenshots and exports. The intended mapping covers SOC 2, ISO/IEC 27001, ISO/IEC 42001, the DPDP Act, the GDPR, RBI and SEBI IT controls, and the logging duties in AI regulation such as Article 12 of the EU AI Act. The auditor checks the evidence themselves, offline, with the public verifier. They do not have to trust the vendor's database. Where records cannot be shared, the target is a zero-knowledge proof of a property. That stays target-only.

For regulators. Two questions are hard to answer from activity logs: who allowed this, and was anything left out? Approvals are receipts. Gaps are receipts. In the target state the log is cosigned by an independent witness, so the operator cannot show different histories to different people. Each connector version has a passport, so a regulator can see exactly which code touched a regulated system.

08 Five examples

What the receipts show.

ScenarioWhat the receipts show
An agent issues a Stripe refundIntent ("refund duplicate charge"), policy limit, approving manager, request digest, Stripe refund id, and reconciliation showing the charge and refund match.
An agent edits 2,000 CRM records overnightOne receipt per change, chained to the run. Reputation lowers the agent's write limit after an unusual rollback rate. In the target state the auditor also gets a zero-knowledge proof that every change was approved.
A GitHub deployment by an AI coding agentThe GitHub connector's passport, the scope used, commit ids, approval and deployment result. A transition receipt is added when the repository token is rotated.
A customer asks to be forgottenThe subject key is destroyed. Receipts stay valid but no longer reveal the erased personal data, and the erasure itself is receipted.
A provider outage for two hoursA coverage receipt with the exact window. Pending obligations are completed afterwards, and the record has no silent gap.
09 Why this is different

Not logs you have to trust. Evidence you can check.

Typical integration platformConnector OS with R-Series (target)
Activity log in the vendor's databaseA signed receipt per action, chained, witnessed and anchored
Trust the vendorVerify independently and offline, with the public verifier
Logging can fail silentlyNo receipt, no write; gaps are explicit receipts
Records "what happened"Records why (intent), who allowed it (policy, approval), what happened and what changed in the provider
Credentials as configurationCredential lifecycle as evidence: grant, refresh, scope, revoke
Connector updates are invisibleEvery connector version has a passport; every change has transition evidence
Evidence ages with today's cryptographyHybrid post-quantum signatures, an archive profile and scheduled renewal
10 Where it stands

In development.

Connector OS with R-Series is in development. Receipts for every connector action are the target; the R-Series pieces it depends on are being built and taken through independent certification before they carry a live Connector OS receipt. In development — talk to us about a design partnership.

In development

11 Lines to remember

Said plainly.

Every action an AI agent takes through a connector leaves a receipt anyone can verify. If it cannot leave a receipt, it does not happen.
The connectors are the reach. R-Series is the trust.
Not logs you have to trust: evidence you can check.
We record the why, the who, the rule and the result.
12 Questions

What people ask us.

Is this running in production today?

No. The page describes the target state, which is in development. Independent certification and production keys come first; after that comes a first Connector OS rollout with its own review.

Why does Connector OS not sign its own receipts?

It is safer that way. The rule is that no DCS product contains cryptography. Every signature comes from one engine with one set of tests, one negative-test corpus and one certifier. A connector bug cannot weaken a signature, because connector code never touches one.

What happens if R-Series is unreachable?

In the target state, write actions stop. If the provider already executed, a durable pending obligation is recorded and the receipt is completed later. If a connector or the log itself is down, a coverage receipt records the window.

Do receipts contain our customers' data?

No. Requests and responses go in as digests only. The profile defaults to the confidential data class. Personal data that must be erasable is handled by destroying a per-subject key, which leaves the receipt valid.

Can the platform operator change a receipt after the fact?

Not without detection. Each receipt is signed and chained into its workflow. In the target state it is included in an append-only log whose checkpoints an independent witness cosigns, so a changed or removed receipt shows up for every verifier.

Can we verify without DCS?

That is the design goal. Receipts check offline with the public verifier and the issuer's published keys, in JavaScript and Python.

Is the zero-knowledge compliance proof available?

Not yet. It is shown here as part of the target state only.

The connectors are the reach. R-Series is the trust.

One engine signs every receipt, and one format carries every product's evidence.

See the universal receiptWhy now

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