Docs, architecture

Control plane in four layers.

RelayOne's control plane separates the governance question into four layers: identity (who is asking), policy (what the decision is), flow (what actually happens), and evidence (what gets signed and stored). Each layer is a distinct concern with its own signing authority.

1. identity who is asking: user, team, agent; SSO, SCIM, Ed25519 session keys 2. policy CEL-compatible rules; decision: allow, reroute, rewrite, block, HITL 3. flow actual traffic shaping: RelayGate edits, R1 reroute targets, TrueCom settlement 4. evidence signed receipts, chain of custody, offline-verifiable evidence bundles
The four layers. Each produces signed state consumed by the next.

Layer 1, identity

Identity is the first thing RelayOne resolves. Session tokens carry an Ed25519 signature tied to an SSO-authenticated user or to a per-agent key issued during provisioning. SCIM keeps the directory in sync. Every downstream receipt carries the identity claim verbatim. An attacker cannot promote a request's identity without a new signature.

Layer 2, policy

Policy is evaluated inline. Rules are CEL-compatible expressions (Google's Common Expression Language; see the policy language page). A rule returns one of: allow, reroute, rewrite, block, or HITL. The decision is signed and attached to the request envelope. Policy versioning uses content-addressed hashes; the evidence bundle pins the policy snapshot for each request.

Layer 3, flow

Flow is what actually happens to the request after the policy decision. In the managed path, RelayGate is the edge; it does the PII strip and credential injection. In the standalone path, your existing middleware handles flow and RelayOne receives only the decision + result envelope. Either way, flow emits its own signed receipt.

Layer 4, evidence

Evidence is the terminal layer. It stores receipts in the database and assembles evidence bundles on the configured windows. Verification is offline and does not require contacting RelayOne. See the evidence page for the bundle schema.

Deployment patterns

Managed path, RelayOne + RelayGate

RelayGate sits in front as the inline edge. RelayOne sits behind as the governance control plane. Best fit when you want the inline rewrite and credential injection that RelayGate provides.

Standalone path, RelayOne only

RelayOne acts as a pure governance plane. Your existing middleware (API gateway, LLM proxy, service mesh) calls out to RelayOne for the policy decision and receives a signed result. Best fit when you already own the inline layer and want to add audit-grade governance without changing the path.

Integration points with the portfolio

  • R1. Reroute targets. When policy decides reroute, R1 runs the internal agent that replaces the external call. R1 on Heroa is the sovereign BC-Canadian option.
  • TrueCom. Commerce substrate. When an agent transacts, TrueCom emits the signed receipt that RelayOne stores in evidence.
  • Veritize. Drift tracking. Where an agent produced output is compared to a ground-truth corpus, Veritize emits drift scores that can attach to evidence receipts.
  • RelayGate. Edge middleware. ContextWorkers do the inline work; they consult RelayOne for policy on each request.