Platform Overview
Consystence is a multi-tenant industrial operations platform. This section explains how the platform is organised: how tenants are provisioned, where their data and runtime live, how people are identified, and how access and licensing are governed. If you are looking for how the software is built rather than how it is organised, start with the architecture overview.
The model has five nesting layers, from the shared front door down to a single plant:
- The account control plane — the shared identity and provisioning front door.
- Cells — self-contained runtime deployments that host one or more tenants.
- Organisations (orgs) — the membership and commercial container; an org owns zero or more tenants, typically one.
- Tenants — the routed, cell-hosted isolation boundary; one per subdomain.
- Sites — physical plant locations, addressed as paths inside a tenant.
flowchart TD
IdP["id.consystence.com<br/>Entra External ID (CIAM)"]
ACP["account.consystence.com<br/>control plane"]
IdP -. authenticates .-> ACP
ACP -- provisions --> Cell["Cell"]
Org["Organisation"] -- owns --> Tenant
Cell --> Tenant["Tenant<br/>{slug}.consystence.com"]
Tenant --> Site["Site<br/>/sites/{code}"]
The account control plane
Section titled “The account control plane”Above every tenant sits a single shared control plane, consystence-account, reachable at account.consystence.com. It is a deliberately thin directory and router, not a second copy of the product. Its job is to be the identity front door, hold the tenant→cell directory, and seed a new tenant into the cell that will host it. It is never in the runtime data path — once DNS resolves a tenant to its cell, traffic goes cell-direct.
Authentication is provided by Entra External ID (a CIAM tenant) at id.consystence.com. The control plane and each cell are independent OpenID Connect relying parties of that one identity provider; they consume OIDC discovery rather than serving it. See Authentication for the full scheme model.
A cell is a self-contained deployment unit: an Orleans cluster, its PostgreSQL store, and its historian, all bound to the tenants it hosts. Cells are internal infrastructure hosts that are never surfaced to users. The platform is designed to scale by adding cells; today a single production cell hosts tenants, and moving a tenant between cells is planned. Two invariants matter here: a customer never spans a cell, and the cell validates Entra tokens itself — the control plane is not in the cell’s authentication path. For the reasoning and the launch topology, see Cell topology.
Organisations and sites
Section titled “Organisations and sites”An organisation is a single customer’s membership and commercial container, and it owns zero or more tenants. The tenant is the routed, cell-hosted isolation boundary: each tenant gets its own subdomain, such as {slug}.consystence.com — origin-level isolation. The slug is a mutable routing label; the stable key is an immutable identifier minted by the control plane. (In the common case an organisation owns a single tenant, so the two are often spoken of together; it can also own several paid tenants and at most one free trial tenant.)
A site is a physical plant location belonging to an org (for example, “Riverbend CHPP”). Critically, a site is a path under the tenant subdomain — {slug}.consystence.com/sites/{code} — never its own top-level domain. (/sites/{code} is the target addressing scheme; today site views are in-app routes under the tenant URL, and sites are addressed by code on the API.) One URL, one login, one tenant boundary covers the fleet view and every site view. A site hosts zero or more server installs, edge devices, and deployed processes; a site provisioned in the cloud but not yet commissioned is valid.
The full hierarchy, the device template/instance model, and the deployable classes are covered in the organisation & site model.
Where each name lives
Section titled “Where each name lives”| Pattern | Scope |
|---|---|
{slug}.consystence.com | Enterprise tenants (fleet + site routes) |
*.consystence.dev | Integrator tenants, trial tenants and individual sandboxes |
consystence.io | One advisory AI web interface, with no per-tenant addresses; the tenant comes from the sign-in, defaulted and switchable — not yet publicly available |
account.consystence.com | Control-plane directory and signup front door |
id.consystence.com | Entra External ID (CIAM) identity provider |
status.consystence.com | Public platform status page |
api.consystence.com | Reserved for a future public API — see the public API surface |
*.consystence.app | Reserved for the future marketplace |
Identity
Section titled “Identity”A person is one account, keyed by their Entra oid — the tenant-immutable object identifier that resolves to the same value across every relying party (the control plane and each cell). The oid is the stable membership key everywhere; nothing joins on usernames or email strings.
Email is a verified attribute, not the identity. It is the invitation channel and the verified-domain gate, never the key that membership hangs on. This means changing an email, holding two corporate emails, or transferring an address are all non-events for membership. There is no email/password login at Consystence — credentials are Entra’s responsibility.
Roles and access
Section titled “Roles and access”Org membership uses exactly three roles: owner, admin, and member. owner is irreducible: an organisation always keeps an owner, which the account console never removes, and the cell’s guard prevents removing the last owner-or-admin. The cloud-elevated set (owner, admin) is authored once at the account and read by the cell, which resolves ordinary membership itself; security-sensitive operations such as deleting an organisation are authorised at the account, so revocation there is instant.
Finer-grained, orthogonal access groups (per cloud, per site) are forthcoming. Today membership is the gate for operating inside a tenant, and each site declares whether it accepts operator commands at all: only a native site does, and commands sent from the hosted cloud also need the site’s remote operation enabled. The full model, including the authority split between account and cell, is on the roles page.
Licensing
Section titled “Licensing”Access to capability is governed by two independent dials:
- An org tier — free by default; the paid Integrator and Enterprise tiers are arranged with our team (see plans). An individual account can also hold a Free sandbox, arranged on request during the beta.
- Counted per-seat SKU pools — SiteServer, Edge, and Agent — each with its own seat quantity and term.
Licences are issued by the account and mediated by the cell; entitlement is tied to provisioned identity, not to hardware. Offline operation is supported via an account-signed artefact, and grace or expiry degrades rather than kills — it never gates an operator’s control writes. The full mechanism is on the licensing page.
Where to go next
Section titled “Where to go next”- New to the platform? Read the core concepts, then follow the quickstart.
- Need the tenant hierarchy in depth? See the organisation & site model.
- Integrating programmatically? Start with Authentication and the API reference.
- Connecting plant equipment? See the edge runtime and PLC communication.