Skip to content
ConsystenceConsystence Docs

Platform Overview

Consystence is a multi-tenant industrial operating system. 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:

  1. The account control plane — the shared identity and provisioning front door.
  2. Cells — self-contained runtime deployments that host one or more tenants.
  3. Organisations (orgs) — the membership and commercial container; an org owns one or more tenants.
  4. Tenants — the routed, cell-hosted isolation boundary; one per subdomain.
  5. 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.

Cells

Section titled “Cells”

A cell is a self-contained deployment unit: an Orleans cluster, its PostgreSQL grain store, and its historian, all bound to the tenants it hosts. Cells are internal infrastructure hosts that are never surfaced to users. The platform scales by adding cells, and a tenant can be migrated between cells on request. 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 one or more tenants. The tenant is the routed, cell-hosted isolation boundary: each tenant gets a subdomain, {slug}.consystence.com, which is also the grain-key prefix — origin-level isolation, the same pattern Slack, Notion, and GitHub use. The slug is a mutable routing label; the stable key is an immutable identifier minted by the control plane. (In the current build an organisation maps 1:1 to its tenant, so the two are often spoken of together.)

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”
PatternScope
{slug}.consystence.comEnterprise-family production tenants (fleet + site routes)
*.consystence.devIntegrator-family tenants and individual sandboxes
{slug}.consystence.ioPer-tenant AI chat front door (apex = sign-in / tenant picker)
account.consystence.comControl-plane directory and signup front door
id.consystence.comEntra External ID (CIAM) identity provider
status.consystence.comPublic platform status page (anonymous /status.json feed)
api.consystence.comReserved for a future public API — see the public API surface
*.consystence.appReserved 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 and every org must keep at least one — invariants ratified, with enforcement forthcoming; the guard shipped today 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 billing and delete-org are authorised at the account, so revocation there is instant.

Finer-grained, orthogonal access groups (per cloud, per site) are forthcoming. In the interim, tenant members have full control within their own tenant. 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 — Basic is the free default; paid tiers span the Integrator (development) and Enterprise (operations) families, bought self-serve through Stripe checkout or granted through a sales-led request → approve flow.
  • Counted per-seat SKU pools — SiteServer, Edge, and Agent — sold as subscriptions.

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”