Cell Topology & Control Plane

Consystence is designed to scale past a single deployment by running independent cells, coordinated by a thin account control plane that sits above them. A cell is a self-contained server deployment that runs tenants; the control plane (consystence-account) is the identity front door, the tenant directory, the DNS router, and the one-shot provisioning authority. It holds each organisation’s roster and each tenant’s owner and admin roles, which the cell mirrors; the rest of a tenant’s membership, its configuration and its runtime state live in the cell.

This page describes the control plane, the cell model, how a cell establishes trust with the account at first boot, and how an org is provisioned onto a cell.

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 account control plane runs in production and drives tenant provisioning end to end. Today a single production cell hosts tenants; treat the multi-cell topology, host patterns and behaviours here as design-of-record that may still move. Site activation and per-seat licence pools are built and pre-GA; the marketplace remains roadmap (see Licensing).

Two planes, one separation of concerns

The platform deliberately splits into a control plane and a set of cells, each owning a strict slice of responsibility.

Concern	Owner
Authentication (issues CIAM tokens)	Entra External ID at id.consystence.com
Tenant identity, DNS, routing, entitlement, provisioning, site declaration/allocation, the organisation roster, tenant owner and admin roles (including the first owner)	Control plane (account.consystence.com)
Tenant membership (mirroring the account’s owners and admins), configuration authoring, site operation, devices, tenant runtime	The cell that hosts the org

The control plane is a stateless directory/routing API (account.consystence.com) plus a separate console UI tier. It is an OIDC relying party of id.consystence.com — it consumes Entra identity, it does not issue it. Critically, the control plane is not in a cell’s authentication path: each cell validates CIAM bearer JWTs directly against the Entra issuer, so a cell keeps working whether or not the account is reachable. Site servers, which are not cells, also sign people in locally with a site PIN that works without the cloud. See Authentication for the credentials each server accepts.

What a cell is

A cell is an independent, always-online server deployment — its own Orleans cluster, its own PostgreSQL, its own historian — bound to the tenants it hosts. You scale by adding a cell rather than by growing one; tenants migrate between cells only on request. Four invariants are binding on the design:

1. The cell host is never surfaced. Users only ever see the org subdomain, never the cell host.
2. A tenant’s home cell is always a lookup, never hardcoded.
3. A customer never spans a cell — one org lives wholly on one cell.
4. A cell is IaC-reproducible — every cell is the same reproducible infrastructure unit.

A cell never assumes a tenant exists: it does not self-provision on a request for an unknown tenant. It runs only what the control plane has provisioned onto it.

Note

A cell is cloud infrastructure operated by Consystence; the site server (which may be offline at a real plant) is a member of a tenant that lives on a cell — it is not itself a cell. The same codebase is published as either a cloud/cell server or a site server. See the layered architecture.

Domain families

Each domain family maps to one role in the topology. A site is always a path under an org’s subdomain (/sites/{code}) — never its own hostname. See the org & site model for the full hierarchy.

Host pattern	Role	Notes
{slug}.consystence.com	Enterprise tenants	Arranged with our team; verified, slug-gated — namespace protection against squatting
{slug}.consystence.dev	Integrator tenants, trial tenants and individual sandboxes	Development-tier domain; free individual sandboxes are arranged on request during the beta and take a chosen slug (validated DNS label); HSTS-preloaded
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, routing, signup, provisioning)	Stays .com for every tier
id.consystence.com	Entra External ID (CIAM)	Issues the bearer JWTs every cell validates
api.consystence.com	Reserved for a future public API	No committed contract — see the gateway

Enterprise tenants live on .com; Integrator tenants, trial tenants and individual sandboxes live on .dev. .app is reserved.

Cell enrolment & trust

Before a cell can host tenants it establishes mutual, operator-approved trust with the account at first boot; a valid enrolment is never auto-trusted, and a platform operator must explicitly approve the cell before it goes active. The credentials issued at enrolment are rotatable and revocable by their issuer, so the account can cut off a cell at once. Cell identity is deliberately cloud-agnostic infrastructure identity — not Entra — so a cell can run on any cloud without coupling to a single identity provider, while human and tenant identity remains the Entra oid.

Org provisioning

The account is the provisioning authority and chokepoint — it owns entitlement checks, rate limiting, tenant identity, slug uniqueness, DNS, and the seeding of the first owner. The cell is the executor: it creates the tenant runtime and recognises the elevated roles, but it never decides whether to provision.

Tenant identity is an immutable identifier minted at the account — the directory’s primary key and the identity the cell adopts. The cell does not mint its own; it adopts exactly the identity the account assigns and continues to use the org slug as its operating key.

The account hands the cell the organisation’s identity, slug and first owner, and the cell confirms adoption. The first owner is recorded at the account in the same step that records the tenant, so a tenant is never recorded without an owner; the cell recognises owner and admin but does not originate them. Provisioning is safe to retry: an interrupted or repeated request resumes or returns the existing organisation, never a duplicate. Roles are exactly owner / admin / member; see Roles.

End-to-end flow

sequenceDiagram
    participant Req as Requester
    participant Acc as Account control plane
    participant Cell as Cell

    Note over Acc,Cell: the cell is already enrolled and approved (one-time)
    Req->>Acc: request a tenant
    Note over Acc: entitlement check · mint tenant identity · assign subdomain
    Acc->>Cell: provision organisation (with its first owner)
    Cell-->>Acc: organisation adopted
    Note over Acc: mark the tenant active

For where cells sit in the wider compute stack, see the architecture overview. Plant controllers are read at the site through an edge that reports to a site server (a site server can also read a ControlLogix directly, read-only, without an edge: early access, enabled per controller by our engineers, off by default); see the on-premises server and the edge.