Architecture Overview

Consystence is an AI-native industrial operating system for monitoring and operating plant equipment. This page is the map: the compute tiers data flows through, the control plane that provisions tenants, the Orleans grain runtime that holds state, and the server-driven UI that renders to multiple clients from one semantic tree.

Two ideas underpin everything that follows:

• One codebase, two published artifacts. The same server code is published as two artifact identities — a cloud organisation/fleet manager (Cloud) and an on-premises, single-organisation site server bound to live equipment (Site). The mode is stamped in at publish time, not selected by runtime configuration. It changes where signals come from and which endpoints are exposed — not the rendering, the grain model, or the wire protocol.
• The server owns state and rendering. Clients are thin. State lives in Orleans virtual-actor grains on the server; the UI is rendered server-side and pushed to the browser as incremental patches.

The four-tier compute topology

A request flows from a user’s client down to physical equipment through four compute tiers. Above the tiers sits the account control plane, which provisions tenant organisations into self-contained cells.

flowchart TB
  CP["Account control plane<br/>account.consystence.com · id.consystence.com"]
  B["Client surface<br/>browser · csy CLI · WinUI3 (roadmap)"]
  subgraph Cell["A cell (the cloud runtime)"]
    S["Consystence Server<br/>Cloud or Site artifact"]
  end
  subgraph Plant["Customer plant"]
    direction TB
    E["Edge runtime<br/>PLCnext VL3 / Nvidia Orin"]
    G["PLCnext border gateway"]
    F["Field devices"]
    E <--> G
    G <--> F
  end
  B <--> S
  S <--> E
  CP -. provisions tenant orgs .-> Cell

1. Consystence Server (the cell runtime)

ASP.NET Core 10, Orleans, and SignalR. This is the organisation runtime. As the Cloud artifact it manages multiple organisations, provisioning, and fleet-level views sourced from a replicated historian; as the Site artifact it is a single-organisation, on-premises server holding live, millisecond-fresh equipment state. The browser connects here over SignalR; edge devices connect over gRPC.

An organisation lives on its own subdomain ({slug}.consystence.com); a site is a path under that subdomain (/sites/{code}), never its own domain. See the organisation and site model.

2. Edge runtime

A .NET 10, single-silo Orleans runtime that runs at the plant. The primary hardware is the Phoenix Contact PLCnext VL3; a GPU-capable Nvidia Orin variant runs the identical runtime. The edge does store-and-forward (a local SQLite buffer) so it tolerates intermittent links, enforces IT/OT network separation, and streams to the server over gRPC — designed for HTTP/3 (QUIC), which the server does not yet serve, so today’s deployments run it over HTTP/2. See the edge runtime for detail.

3. PLCnext border gateway

The primary path to Consystence-managed equipment. The edge runtime reads and writes the PLCnext Global Data Space (GDS) / PORT variables over gRPC on a local Unix domain socket; the PLCnext in turn speaks CIP / EtherNet-IP to field devices on the internal OT network. Alongside that, the edge natively acquires from third-party and legacy controllers with its own protocol drivers — EtherNet/IP CIP and Modbus TCP today, further protocols planned — without a broker SCADA in the data path; the original direct-CIP-to-ControlLogix topology survives within that interop path.

Note

The edge and the site server share one driver layer: the same pure-.NET EtherNet/IP, PLCnext GDS, and Modbus TCP drivers run on either tier, so a controller that is not mapped to an edge can be acquired directly by the site server. See PLC communication.

4. Field devices

Controllers, variable-frequency drives, IO racks, sensors, and protection relays. Consystence uses the vendor-neutral term controller (ControlLogix, PLCnext, Modbus are all controllers) rather than “PLC”. The engineering model below them is controller → module → channel → tag/register; see core concepts.

The account control plane and cells

Above the cells sits the account control plane (consystence-account), reachable at account.consystence.com, with identity provided by the Entra External ID (CIAM) tenant at id.consystence.com. It is a thin directory, router, and signup front door: it provisions tenant organisations into cells and resolves which cell a tenant lives on. It deliberately does not own membership, configuration, or tenant state — those live inside the cell.

A cell is a fully self-contained deployment: its own Orleans cluster, its own PostgreSQL, its own historian, bound to a set of tenants. You scale the platform by adding cells, not by growing one cluster. A tenant never spans a cell, and the cell host itself is never surfaced to users — customers only ever see {slug}.consystence.com. Each cell validates Entra/CIAM tokens directly, so the control plane stays out of the request and authentication path.

Not yet generally available

The account control plane, provisioning, and the tier/seat licensing flows run in production behind launch gates — new tenants currently wait on operator approval, and self-serve signup is not yet GA. The multi-cell topology is architectural direction: today a single production cell serves tenants, and each deployment is a self-contained cluster in the cell sense.

The cell-versus-cluster choice — and why it is preferred over a single multi-tenant cluster — is covered in cell topology.

Orleans virtual-actor runtime

All stateful server objects are Orleans grains (virtual actors). A grain is a single-threaded, addressable object that Orleans activates on demand and places transparently across the cluster; the application never manages activation, locking, or placement. State is held in virtual actors keyed by the organisation/site hierarchy, which is also the tenant-isolation boundary. A connected client’s session state, a commissioned device’s runtime state, and the command audit trail are each held in their own grains. Platform services that are not stateful — authentication, the admin surface, and the public API gateway — are plain ASP.NET Core, not Orleans.

A design property worth calling out: grain activation scales with infrastructure (controllers, devices, sessions), not with tag count. Tags are batched and evaluated per device rather than per tag, so activation count tracks the equipment on site rather than the number of tags being polled.

Server-driven UI

Consystence does not ship a single-page-application framework. The server builds a semantic UI tree — a renderer-agnostic tree of primitives (View, Card, Stack, StateBadge, Gauge, Button, Table, …) describing what a surface expresses, not how it paints. That tree reaches clients as a JSON wire format over the /hubs/ui-wire SignalR hub:

• Browser — the browser wire renderer is the default browser surface: it consumes the wire format (initial render, incremental patches, and client actions) on /hubs/ui-wire and renders the server-resolved tree as DOM. The previous default — server-rendered HTML plus incremental DOM patches over SignalR (/hubs/ui-page) — is legacy, no longer served by default, and the HTML branch is being deleted.
• CLI — the csy command-line client (csy ui), the first shipped consumer of the wire format, rendering the same tree in the terminal over the same hub.
• WinUI3 — a native Windows renderer for control rooms and engineer workstations (roadmap; it will consume the wire format like the CLI and browser).

What stays invariant across renderers is the semantic tree, not any one client. New renderers consume the same wire protocol rather than growing private ones — which is what lets the AI compose and configure surfaces entirely server-side, with no privileged client.

AI is advisory-only

The platform uses AI to configure equipment models, answer questions about plant state, classify alarms and events, and explain behaviour. The LLM operates the same tool surface a human engineer would — browsing tags, binding equipment to data points, composing scenes.

The advisory plane is tiered. A site server can answer grounded advisory questions with a site-local model that runs on-site and is offline-capable (so its inference stays at the plant); the cloud ladder above it has two rungs — a non-apex tier and an apex reasoning tier — with the site-local model converging on the non-apex model as roadmap. The cloud tiers are served by stateless, per-region advisory gateways that keep inference in-region for data residency. A site server relays cloud-tier calls through the cloud cell, where per-tenant usage is metered and model access is entitlement-gated. Whichever tier answers, it grounds its response in tenant data through a read-only data seam only — it holds no path to the control-write surface, so the advisory plane is structurally incapable of a control write. See AI architecture for the full picture.

AI never commands equipment

AI in Consystence is advisory-only. It configures, queries, classifies, and explains — it does not issue control commands to equipment. Control authority and hard interlocks live in the controllers, IO modules, and safety relays at the plant, outside the AI’s reach. Any “edge ML” or on-edge inference is roadmap and remains advisory. When you read about AI alongside control anywhere in these docs, this boundary holds.

Identity and access, in brief

Authentication is a multi-scheme policy selector: Entra-issued CIAM bearer JWTs for users, tenant API keys (csk_ prefix) for machine clients, and an offline-capable site-PIN scheme for on-premises site login. There is no email/password login in Consystence itself — credentials are Entra’s responsibility. The stable membership identity is the Entra oid, not email. Organisation membership has exactly three roles: owner, admin, member — and site-level operational roles are a separate plane: on a site server, site functions are authorised by the user’s site role, not their organisation role. See authentication and roles.

Commercial entitlement is a separate concern — an organisation tier plus counted per-seat pools — and is designed to degrade rather than kill on expiry, never gating operator control writes. See licensing.

Where to go next

• Cell topology — cells, the control plane, and why not one big cluster.
• Organisation and site model — subdomains, sites as paths, and tenant isolation.
• Edge runtime and PLC communication — the path to equipment in detail.
• AI architecture — the tiered advisory plane and the advisory-only boundary.
• Core concepts — device types, instances, and the engineering model.
• API reference — the cell-direct /api/* surface.