Organisations & Sites

This is the canonical reference for how Consystence models tenancy: accounts (people), organisations (tenants), and sites (locations). It defines what is identified by what, how URLs are constructed, how the same server binary runs in two modes, and where licence tiers and membership roles attach.

Pre-GA surfaces

The account control plane (account.consystence.com), cells, Stripe billing, and tier entitlements are implemented and run in production behind launch gates — operator tenant approval, and a purchasing kill-switch. Self-serve signup is not yet generally available, and the marketplace is still design-only. Where a section describes these, 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 one or more tenants	Account-minted immutable UUID (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
UUID	Immutable, account-minted (org_*). The directory primary key, the provisioning idempotency key, and the cross-repo correlation key. Used in all internal references.
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 — Basic (free), or a paid tier from the Integrator or Enterprise family, granted by Stripe checkout (self-serve tiers) or request → approve (sales-led). See Licensing.

The UUID is identity; the slug is a label. Internal grains, isolation claims, licences, and site/scene references resolve through the UUID (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 organisation lives at its own subdomain on the canonical production domain:

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

One subdomain, one login, one tenant boundary — the Slack / Notion / Linear / GitHub pattern.

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. Cannot demote or revoke an owner.
member	Belongs to the tenant; no tenant-admin authority.

Two invariants are ratified, with enforcement forthcoming: an org must always retain ≥1 owner, and an admin can never strip an owner (so an integrator’s admin operating inside a partner tenant cannot seize the partner’s ownership). The guard shipped today is narrower — it 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 Basic org (which 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; until they ship, the interim posture is that any tenant member has full control within their own tenant — the boundary that protects you is the cross-tenant isolation, not per-role gating inside the org.

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. The declared-site count is capped by the tenant’s tier, and the declaration is fed down to the cell. Removing a declared site frees its slot against the cap — it 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 organisation reference — the org UUID in the account directory; the cell’s site records currently carry the org 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["Organisation<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 organisation manager running on a cell. It provides the fleet view across sites and acts as the control plane for identity, licensing, observability, and provisioning. 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.

The cloud pushes site identity, licence, and edge↔server mapping down to the site (online, or offline via removable media for air-gapped installs); the site owns its live model and control. Above the cells, the account control plane provisions tenant orgs into cells.

See Cell topology and the Architecture overview for how cells host orgs, 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	Early — registry only
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 — a digital workflow (forms, procedures, inspections) not tied to equipment I/O. Today an Application is a named registry entry only — the workflow machinery (forms, inspections, checklists, shift handover) is 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, and the platform’s AI configures, queries, classifies, and explains. AI never commands equipment. Hard interlocks live in the IO modules and safety relays, not in software. On-edge ML is roadmap; today these assets are advisory.

Licence tiers

Each organisation holds a tier as an org-keyed property. Basic is the free default — an org with no paid tier, members-only. Paid tiers form two families:

Family	Tiers	Posture
Integrator (development)	Integrator, Integrator Pro, Certified Partner (sales-led)	For organisations that author and deploy templates; tenants live on .dev.
Enterprise (operations)	SME, Enterprise, Enterprise Unlimited (sales-led)	For organisations that operate plants; tenants live on .com.

A checkout-priced tier (Integrator, Integrator Pro, SME, Enterprise) is bought self-serve through Stripe checkout: payment mints the entitlement directly (Available), with no operator approval. The sales-led tiers (Certified Partner, Enterprise Unlimited) and complimentary grants keep the request → approve flow: the tier is requested, and an operator approves it (Requested → Available). Either way, the entitlement is Consumed when a paid tenant provisions against it, and at launch every new tenant additionally passes an operator tenant-approval gate. Within a family an organisation upgrades in place (Integrator → Integrator Pro, SME → Enterprise); a denied request may be re-requested.

Tiers carry operating entitlements enforced by the cell: declared-site caps (SME 1, Enterprise 5, Enterprise Unlimited uncapped; the integrator family is uncapped), historian retention (183 days for the integrator family), and team seats (Integrator 5, Integrator Pro 15).

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-family production tenants	acme.consystence.com
*.consystence.dev	Integrator-family tenants and individual-account sandboxes	dev-acme.consystence.dev
{slug}.consystence.io	Per-tenant AI chat front door (the apex is the sign-in / tenant-picker door)	acme.consystence.io
account.consystence.com	Account control plane / provisioning console	—
id.consystence.com	Entra External ID — the OIDC issuer	—
status.consystence.com	Public platform status page (anonymous /status.json feed)	—
*.consystence.ai	AI cells — per-region advisory inference (pre-GA)	au1.consystence.ai
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 family) or .dev (integrator family). A free Basic org 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.