Organisations & Sites

This is the canonical reference for how Consystence models tenancy: accounts (people), organisations and the tenants they own, and sites (locations). It defines what is identified by what, how URLs are constructed, how one codebase is published as two server artifacts (Site and Cloud), and where licence tiers and membership roles attach.

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. Where a section describes the account control plane (account.consystence.com), cells or tiers, treat it as pre-GA.

The three identities

Concept	What it is	Identity key
Account	One per individual person	Entra oid (object id)
Organisation	The membership, ownership, and commercial boundary — it owns zero or more tenants, typically one	Account-minted immutable id (org_…)
Site	A physical location belonging to an org	Immutable GUID; addressed by a path code

An account gains capabilities only through org membership — it has no inherent class of its own. The same person can be an admin in one org and a member in another simultaneously.

Membership is keyed on oid, not email

The stable membership key is the Entra oid — the tenant-immutable object id, identical across every relying party (the account console and each cell), so one person resolves to one identity everywhere. Email is a verified attribute and the invitation channel — never the membership key. A membership may optionally carry a preferredEmail chosen from the account’s verified emails, but authorisation is always resolved against the oid.

See Authentication for how identities are issued and verified.

Organisations

An organisation is the membership, ownership, and commercial boundary — the entity that owns tenants and carries the tier and the member roster. A tenant is the operational workspace it owns: the unit of isolation, addressed by an immutable id, a slug, and a subdomain. In the common case an organisation owns a single tenant, so the two are often spoken of together; the fields below cover both.

Field	Description
Organisation id	Immutable, account-minted (org_…). Identifies the organisation in the account console.
Tenant id	Immutable, account-minted when the tenant is provisioned. Also of the form org_…, but distinct from its organisation’s id. The directory key and the provisioning idempotency key.
Slug	Mutable, user-facing routing label. Becomes the subdomain. Unique per canonical domain, not globally — acme may exist once on .com and once on .dev.
Name	Display name.
Tier	Org-keyed licence tier — free by default, or a paid Integrator or Enterprise tier arranged with our team. See Licensing.

The ids are identity; the slug is a label. Internal records, isolation claims, licences, and site/scene references resolve through these immutable ids (or the slug as the cell’s operating key) — never through a value a client could spoof. The slug is deliberately changeable but strongly discouraged: renaming it triggers DNS propagation, TLS re-issuance, and broken external links, much like renaming a GitHub organisation. Slug changes are owner-only and not yet permitted in the current build.

Subdomain

Each tenant lives at its own subdomain on its canonical domain — .com for Enterprise tenants, .dev for Integrator tenants, trials and sandboxes (see Domain families):

{slug}.consystence.com        e.g.  acme.consystence.com

One URL, one login, one tenant boundary.

Membership roles

Org membership carries exactly one of three roles:

Role	Authority
owner	The tenant’s irreducible root authority. Full administration; only an owner may manage owners.
admin	Full tenant administration — manage members, domains, licences, sites.
member	Belongs to the tenant; no tenant-admin authority.

An organisation always keeps an owner: the account console never removes an organisation’s owner, and the cell mirrors the owner and admin set the account holds. The cell’s own guard prevents removing or demoting the last owner-or-admin member.

The table above is the cell tenant-membership model. The account console’s roster for a free organisation (one that holds no paid tenant) is currently owner / member only, with a single owner — it has no admin role yet.

Note

The older five-role model (owner / admin / engineer / operator / viewer) is gone. Finer-grained, orthogonal access groups are forthcoming; today membership is the gate for operating inside a tenant. Each site also declares whether it accepts operator commands at all: only a site where Consystence is declared the operator surface (native) does. A site declared display-only, a site operated from another SCADA and a site with no declaration refuse every plant write, and commands sent from the hosted cloud also need the site’s remote operation enabled.

See Roles & permissions for the full authority model and the two-gate (membership vs. operation) split.

Sites

A site is a physical location belonging to an organisation — a plant, a CHPP, a workshop.

Sites are declared account-side, per tenant: an owner declares a site on the tenant’s Sites page in the account console, and the declaration is fed down to the cell. Removing a declared site never touches the cell’s operational data for that site. Site-activation codes are issued against a declared site.

Field	Description
GUID	Immutable internal id.
Code	Reserved at creation; the path segment under the org subdomain.
Name	Display name (e.g. “Riverbend CHPP”).
Org	Parent reference — the owning tenant’s id in the account directory (sites are declared per tenant); the cell’s site records currently carry the tenant’s slug as the operating key.
Location	GPS coordinates / address.

A site is a path route under the org subdomain — never its own top-level domain:

acme.consystence.com/sites/{code}

Note

/sites/{code} is the target addressing scheme. In the current build, site views are in-app routes under the tenant URL, and site-by-code addressing lives on the API (/api/sites/{code}). The load-bearing invariant — a site is always a path under the org subdomain, never its own domain — holds either way.

There is no .site TLD and no per-site subdomain; the fleet dashboard and every site view are routes under one tenant URL. A site may host zero or more server installs, edge runtimes, and deployables. A site with zero installs is valid — declared in the cloud but not yet commissioned.

graph TD
  CP["Account control plane<br/>account.consystence.com"] -->|provisions| ORG["Tenant<br/>{slug}.consystence.com"]
  ORG --> S1["Site<br/>/sites/{code}"]
  ORG --> S2["Site<br/>/sites/{code}"]
  S1 --> SRV["Site server"]
  S1 --> EDGE["Edge runtime"]

Dual-mode servers

Consystence ships as two published server artifacts — Site and Cloud — with the mode baked into each at build time, not selected by runtime configuration:

• Cloud — the multi-tenant server running on a cell, where each tenant’s hosted workspace lives. It provides the fleet view across a tenant’s sites, validates sign-ins itself, and relays site activation and mediates licensing for the account control plane, which keeps the identity directory, provisions tenants, and is the sole licence issuer. The cloud is never in the runtime data path.
• Site — an on-premises server at a site. It is authoritative for its own model configuration and is offline-capable, continuing to operate when disconnected.

A site server is enrolled once, by redeeming a one-time activation code through its hosting cell: it receives its identity and, where a seat is available, a signed licence that it then verifies offline. Activation for fully air-gapped sites is roadmap. Delivering configuration from the site model to edges automatically (from the site server, or from the cloud where a site has no site server) is roadmap; today each edge runs on its own local settings. Above the cells, the account control plane provisions tenants into cells.

See Cell topology and the Architecture overview for how cells host tenants, and the Edge runtime for what runs at a site.

Deployable classes

A site hosts deployables, each following a template → instance pattern (an integrator authors a template; an instance is stamped out at a specific site):

Class	Domain	Status
Process	Physical plant control — pump station, conveyor, CHPP circuit	Active
Application	Digital workflows — inspections, checklists, shift handover	Roadmap — not yet built
Mission	Robotic operations — stockpile survey, yard inspection	Future

• Process — a running instance of an industrial process with real equipment, I/O, and control: device instances, scene graphs, alarm definitions, trend configuration, and control logic. Processes are deliberately independent in the current model (no shared device instances or cross-process state); shared physical equipment is modelled as cross-referenced instances in each process, because ambiguous control authority is a safety concern for a mining audience.
• Application (roadmap) — a digital workflow (forms, procedures, inspections) not tied to equipment I/O. Not yet built.
• Mission (future) — robotic operations from a base skid, where the edge runtime forks into a robot variant for UAV/rover survey work; mission outputs feed back into Processes as tags.

AI is advisory-only

Templates may reference predictive or “Edge ML” assets. The platform’s AI reads, explains and recommends; it never commands equipment. Hard interlocks are enforced at the plant, in deterministic controller logic and hardwired safety relays — never in a model. On-edge ML is roadmap; today these assets are advisory.

Licence tiers

Consystence offers three public tiers. An organisation holds its tier as an org-keyed property; an organisation with no paid tier is free and members-only.

Tier	Held by	Posture
Free sandbox	An individual account	A personal sandbox tenant on .dev; arranged on request during the beta.
Integrator	An organisation	For organisations that author and deploy templates; tenants live on .dev.
Enterprise	An organisation	For organisations that operate plants; tenants live on .com.

Integrator and Enterprise access is arranged with our team; see plans. A paid tenant is provisioned against an entitlement the organisation holds, and the entitlement is consumed when the tenant provisions.

A tier carries operating entitlements, such as the historian’s retention period, which the cell applies.

Alongside the org tier sit counted, per-seat SKU pools (SiteServer / Edge / Agent), account-issued and cell-mediated. Licensing is bound to a provisioned identity, not a hardware id; offline operation uses an account-signed artifact; and crucially, grace and expiry degrade rather than kill — they never gate operator control writes. The full mechanism, including the SKU pools and offline artifacts, is described in Licensing.

Domain families

Pattern	Scope	Example
{slug}.consystence.com	Enterprise tenants	acme.consystence.com
*.consystence.dev	Integrator tenants, trial tenants and individual-account sandboxes	dev-acme.consystence.dev
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	Account control plane / provisioning console	—
id.consystence.com	Entra External ID — the OIDC issuer	—
status.consystence.com	Public platform status page	—
api.consystence.com	Reserved for a future public API	No committed contract — see the public API surface
*.consystence.app	Reserved for the future marketplace	—

Two distinctions are load-bearing:

• A site is always a path under the org subdomain (/sites/{code}) — it never gets its own TLD.
• A sandbox is account-level, provisioned under an individual account onto .dev and holding no org; an org-owned tenant lands on .com (Enterprise) or .dev (Integrator, and trials). A free organisation routes nowhere on its own — an org has no slug or subdomain of its own; its tenants do — though it can hold the organisation’s one free trial (simulation) tenant.

New to the platform? Start with the core concepts or the quickstart, or return to the platform overview.