Key Concepts

Consystence is an industrial operations platform built for mining, coal handling and preparation plants (CHPPs), and process plants. This page is a primer on the concepts you will meet everywhere else in these docs. Each section is deliberately short and links to the page that covers it in depth.

If you would rather see it running first, start with the quickstart and come back here for the “why”.

The deployment topology

A Consystence deployment runs from the client down to the plant’s controllers. The platform tiers are site server → cloud, with an optional edge beside the controllers, each degrading gracefully if the link to the next is lost; the client and the plant bracket those tiers. Each part has a narrow job and a defined protocol to its neighbour:

flowchart TB
  CP["Account control plane<br/>account.consystence.com · id.consystence.com"]
  B["Client<br/>browser · csy CLI"]
  S["Consystence Server<br/>Site or Cloud mode"]
  E["Edge runtime<br/>optional"]
  C["Controllers<br/>ControlLogix · PLCnext"]
  G["PLCnext border gateway<br/>optional target topology"]
  F["Field devices"]
  CP -. provisions tenants .-> S
  B --> S
  S -.->|"optional edge"| E
  E -.-> C
  S -.->|"direct ControlLogix reads (early access)"| C
  C --> F
  E -.-> G
  G -.-> F

• Client — the browser is the main client today, talking to the server over SignalR. The csy CLI is a first-class peer client; a Windows-native client is on the roadmap (see Server-driven UI).
• Consystence Server — the tenant runtime (sessions, the process and device model, the real-time pipeline). Next to a plant it runs in Site mode and takes plant data from an optional edge, or reads a ControlLogix directly (early access, off by default); in the cloud the same code runs in Cloud mode for fleet views and analysis.
• Edge runtime — an optional, network-resilient runtime next to the plant that reads the controllers, buffers through link outages and feeds the site server (see the edge). In our workshop it runs on an Nvidia Jetson Orin. The Phoenix Contact PLCnext VL3 is a target platform for it, and we are proving the edge runtime for the VL3 on a Linux container in our workshop.
• Controllers — Rockwell ControlLogix and Phoenix Contact PLCnext today. They are read by the site server (ControlLogix, early access) or through an optional edge. The site server reads a ControlLogix directly, read-only, without an edge. This is in early access: our engineers enable it per controller, and it has run at a site trial since 28 October 2026. Off by default. A PLCnext is read through an edge. Production control stays on the plant’s existing control system.
• PLCnext border gateway — an accepted target topology, demonstrated in our workshop, in which a PLCnext keeps a field network behind it and the edge reads the plant through it. It is one option, not a requirement.
• Field devices — IO racks, VFDs, protection relays and sensors.

The edge streams to the server over gRPC (HTTP/2 today; HTTP/3/QUIC is planned but not yet enabled). The edge reaches controllers through a driver layer it shares with the server: EtherNet/IP CIP for ControlLogix, and gRPC (GDS) for PLCnext, over a Unix domain socket when co-located or TCP when the PLCnext is containerised or remote. Modbus TCP and OPC UA runtime drivers are roadmap. In the border-gateway topology, the PLCnext in turn speaks EtherNet/IP CIP to the field network behind it. The full picture is in the architecture overview and PLC communication.

The account control plane and cells

Above the cells sits the account control plane (account.consystence.com, with id.consystence.com as the identity provider). It is where individual accounts live, where organisations are created, and from which tenants are provisioned into cells. A cell is a server deployment that hosts tenants, each reached through its own public subdomain ({slug}.consystence.com / .dev); the control plane is never in the runtime data path between a plant and its operators.

Public beta

The hosted service is in public beta. During the beta, free individual sandboxes and paid organisations are both arranged with our team: request access. The marketplace is roadmap.

See cell topology for how cells and the control plane fit together.

Organisations and tenants

An organisation is the account-level ownership and billing boundary: a customer, an integrator, or an internal team. It holds members and billing, and contains zero or more tenants, typically one. A tenant is the provisioned, routed unit: it runs in one cell at its own subdomain and contains the sites. The hierarchy is user → organisation → tenant → site. Older API fields and CLI flags say org where they mean the tenant, for example --org <tenant-slug>. A tenant has:

• an immutable, account-minted id (org_ followed by 32 hex digits; the prefix is historical), the stable correlation key in records and references;
• a user-facing slug, the subdomain under the tenant’s canonical domain: {slug}.consystence.com for Enterprise tenants, {slug}.consystence.dev for Integrator tenants and sandboxes. Slug rename is not currently supported;
• a licence tier, billed to its organisation (see Licensing).

A person’s account has no inherent power of its own; it gains capabilities purely through membership in one or more tenants. The same account can be an administrator in one tenant and a plain member in another. The platform overview and the org & site model go deeper.

Identity: the Entra oid

Identity is provided by Entra External ID (Microsoft’s customer identity / CIAM product), reached via id.consystence.com. The stable membership key for a person is the Entra oid — the tenant-immutable object id that is the same across every relying party. Email is a verified attribute and the invitation channel; it is not the identity key, and it can change without changing who the person is.

For hosted (cloud) sign-in, Entra owns the login experience: Consystence runs no email/password flow, registration, password reset or MFA of its own. Site servers have their own operator sign-in (email and PIN), and site sign-in credentials cannot authenticate to the hosted cloud service. See authentication for the full model.

Sites

A site is a physical location under a tenant — a mine, a wash plant, a pump station. Crucially, a site is a path under the tenant’s subdomain, not its own domain. The target addressing scheme is:

acme.consystence.com/sites/riverbend

Today site views are in-app routes under the tenant URL, and the API addresses a site by code at /api/sites/{code}. In the hosted service: one URL, one login, one tenant boundary. There is no separate .site domain.

A site hosts the server and edge installs that run its plant. One server source tree ships as two mode-baked artifacts — the mode is stamped at publish time, not read from configuration:

• Site — an on-prem (or site-adjacent) server serving live controller state to operators and site engineers;
• Cloud — a cloud/cell server serving fleet views, provisioning, and analysis from a replicated historian, with no dependency on live site state.

This dual-mode design is detailed in the org & site model.

Membership roles

Tenant membership carries exactly one of three roles:

Role	What it means
owner	Full control, including billing and deleting the tenant.
admin	Manage the tenant’s members, sites, and configuration.
member	Belongs to the tenant, with no tenant-administration authority; until access groups land, may operate sites that accept Consystence commands.

The guarded invariant is admin authority: a tenant always retains at least one member who is an owner or an admin — a demotion or removal that would leave zero is rejected.

Authority is two-tier: the tenant role governs tenant management and membership, and a separate site role governs site functions for people who sign in to a site server by email and PIN. Until per-capability access lands, tenant membership is also the gate for operating a site that accepts Consystence commands. Platform administration is a separate Consystence-staff concern — not a tenant role. See roles.

Device types and instances

Consystence separates the reusable definition of a piece of equipment from each deployed copy of it:

• A device type is a reusable template with a dot-notation id (for example consystence.pump.centrifugal). It declares the equipment’s tags, states, alarms, and commands once.
• A device instance is a type commissioned at a specific site. It carries a site-local AssetNumber (for example PP-01) and the confirmed tag mappings to real hardware.

Authoring against types and stamping out instances keeps a fleet of pumps consistent and makes type-level reasoning (“show me every centrifugal pump across all sites”) tractable.

Device types live in a global type catalogue shared across tenants, loaded from Consystence’s first-party libraries at startup, rather than being authored per tenant. An instance can carry per-instance overrides where a placement deviates from its type — and because types are catalogue-owned, a tenant export references type ids but carries no type definitions.

The engineering model: controller, module, channel, tag

Beneath the device model is a vendor-neutral hierarchy. Consystence says controller, never “PLC” (ControlLogix and PLCnext today):

Controller   owns the backplane and scan cycle; root of all IO ownership
  └── Module   passive hardware (DI, DO, AI, AO, comms, safety, compute)
        └── Channel   an individual IO point
              └── Tag / register   a named value in the controller's tag register

In the Consystence model, each such value is a data point: it has a dataType (Bool, SInt, Int, DInt, Real, or String), an access mode (Read, Write, or ReadWrite), and a physicalRole. The model’s hard rule (register gating) is that no model may reference a tag path that does not exist in a controller’s tag register — but note that commission-time enforcement is not yet implemented, so a bad mapping surfaces at runtime instead: samples for unknown tag paths are dropped, and reads/writes against them fail. PLC communication covers how these tags are read and written.

Server-driven UI

The UI is server-driven. The server holds the state and renders a semantic UI tree — a renderer-agnostic tree of primitives describing what a surface expresses, not how it looks. That one tree, carried over a single JSON wire format, drives two shipped clients, with a third planned:

• the browser wire renderer (the only browser surface) — the tree is carried over SignalR and rendered in the browser;
• the csy CLI (csy ui), a peer renderer in the terminal;
• a native WinUI3 client for Windows control rooms (planned).

State lives in Orleans virtual-actor grains; each interactive UI session is backed by its own server-side session actor. The architecture overview explains the rendering pipeline and grain topology.

Advisory-only AI

Advisory AI runs through the platform. It reads tags, alarms and history, explains plant state in plain language, runs engineering calculations, and can propose a command for an operator to review. Its tools read, calculate and propose; none of them writes to a controller or changes the plant model.

AI is advisory-only

The AI never commands equipment. It reads, explains and proposes, and has no path to issue a control write: an operator reviews a proposed command and issues it through the normal command path. Hard interlocks and safety functions live in deterministic controller logic and hardwired safety relays — never in the server or AI path. On-edge machine-learning inference is roadmap, not a shipping capability.

This advisory boundary is a load-bearing safety property of the platform, and it holds end to end.

Authentication

Consystence accepts three kinds of credential; which one a client sends depends on who or what is calling:

Credential	Sent by	Issued by
Organisation sign-in (Entra)	Browsers (a cookie holds a server-side session, which hands the browser a bearer token for its SignalR connection) and the csy CLI (as a bearer token)	id.consystence.com
X-Api-Key header	Integrations and scripts	A tenant API key, prefix csk_
Site PIN sign-in	People signing in to a site server, with or without a cloud link	The site server itself, as a locally signed token

Tenant API keys are minted at /api/admin/api-keys and the plaintext key is shown once. Keys are read-only by default. An operator key covers one person and one native (simulated) site for at most 30 days, and can issue commands and acknowledge alarms on that site. Hosted sign-in has no separate Consystence login, registration or password flow; site servers add their own PIN sign-in. Full detail is on the authentication and API keys pages; the cell’s /api/* surface is documented in the API reference.

Licensing

Licensing has two independent dimensions:

• an organisation tier, one of the three public plans: Free sandbox, Integrator or Enterprise;
• counted SKU pools (SiteServer, Edge, Agent): install capacity, drawn down as installs are provisioned.

Licences are account-issued and cell-mediated, bound to a provisioned identity rather than hardware. Offline operation is supported via an account-signed ECDSA/JWKS artifact. Critically, licence grace and expiry degrade rather than kill, and never gate operator commands — a plant keeps running.

Plans

Paid tiers are arranged with our team; see plans on consystence.com. The licensing page describes the full model.

Where to next

• Quickstart — get hands-on.
• Architecture overview — the full system shape.
• Cell topology — cells and the control plane.
• The edge and PLC communication — how Consystence reaches field hardware.
• Platform, org & site model, authentication, roles, and licensing — the tenancy and access model.