Licensing & Billing

Consystence licensing has two orthogonal axes. An organisation tier describes the commercial relationship and carries the tenant’s operating entitlements (declared-site caps, historian retention, team seats); counted per-seat SKU pools grant the capacity to run installs. They are independent: the tier does not imply seats, and seats do not imply a tier.

The model is deliberately provisioned-identity based, not hardware-bound — a licence binds to a registration secret written once when a server is provisioned, so the snapshot, clone, migrate, and recreate operations this fleet runs constantly do not invalidate a licence. And a licensing condition can never stop a running plant: expiry and revocation degrade a server, they do not kill it, and they never gate operator control writes.

Implemented, not yet GA

The commercial surface on this page — Stripe billing (tier and per-seat licence subscriptions), tier provisioning, per-seat SKU pools, the account-side licence signer, and offline verify/enforce on the site — is implemented and runs in production behind launch gates (operator tenant approval, and a purchasing kill-switch). Self-serve signup is not yet generally available. During the beta, the platform is offered for evaluation, authoring and simulation, and commissioning trials alongside existing SCADA — production control stays with your existing systems until the beta label comes off. Some pieces — seat release on decommission, and fully air-gapped activation transport — are roadmap, and are marked as such where they appear below.

The two axes

Axis	What it is	Granted by	Enforced where
Organisation tier	Basic (free) plus the Integrator and Enterprise tier families — the commercial relationship	Stripe checkout (self-serve tiers) or request → approve (sales-led)	Account grants; cell enforces the tier’s operating limits
SKU pools	Counted per-seat capacity to run installs	Stripe subscription (per-seat)	Cell mediates; site/edge enforce

Basic is the free default — an organisation with no paid tier. Paid tiers form two families:

• the Integrator (development) family — Integrator, Integrator Pro, and the sales-led Certified Partner — for organisations that author and deploy templates, with tenants on .dev;
• the Enterprise (operations) family — SME, Enterprise, and the sales-led Enterprise Unlimited — for organisations that operate plants, with tenants on .com.

The checkout-priced tiers (Integrator, Integrator Pro, SME, Enterprise) are bought self-serve through Stripe checkout — payment mints the entitlement, with no operator approval. The sales-led tiers (Certified Partner, Enterprise Unlimited) and complimentary grants use a request → approve flow: the organisation requests, an operator approves. Within a family, an organisation upgrades in place (Integrator → Integrator Pro, SME → Enterprise).

A tier carries operating entitlements enforced by the cell: a declared-site cap (SME 1, Enterprise 5, Enterprise Unlimited uncapped; the integrator family is uncapped), historian retention (the integrator family is capped at 183 days), and team seats (Integrator 5, Integrator Pro 15). Tiers still do not unlock installs — install capacity is bought separately as SKU pools, so a single organisation’s tier and its seat counts move independently.

Per-seat SKU pools

A licence is a counted, SKU’d, expiring pool keyed to the organisation (by the organisation’s account-minted UUID — organisations do not have an Entra oid; that is a person’s key). Each pool carries a SKU, a seat quantity, a term/expiry, a status, and a set of assignments mapping consumed seats to installs.

Three SKUs are counted independently:

SKU	Covers
SiteServer	A site-server install (a server running in Site mode)
Edge	An edge-runtime install
Agent	An engineering-agent install (below)

The engineering agent behind the Agent seat is a small service installed on an engineering host — an Ignition gateway server or a vendor-tool workstation — that carries out gated engineering operations against that host on the platform’s behalf: it enrols with the site server, polls outbound-only for approved jobs, takes a backup before any change, applies only allow-listed targets, and holds no runtime authority — it is never a participant in the control path.

A pool is distinct from an entitlement. An entitlement is a single-use right to provision one paid tenant; a licence pool has quantity, SKU, expiry, and per-seat assignment that an entitlement does not.

Sandbox quota and provisioning limits

Tenant provisioning sits behind a bounded wall (self-serve signup is not yet GA, and at launch every new tenant passes an operator approval gate):

• Each account gets one free individual sandbox tenant.
• Each organisation gets one free trial (simulation) tenant — ever. A trial tenant can be converted in place to an integrator-family paid tier; it cannot mint site-activation codes.
• Provisioning attempts are rate-limited per account and globally (429), beneath a global tenant ceiling (409).
• Paid-tier provisioning requires an org-keyed entitlement — denied with 402 until a Stripe checkout mints one, or an operator grants one (the sales-led and comp paths).

See tenant provisioning and the provisioning API for the full wall semantics.

Purchase = Stripe subscription with quantity

Each SKU has a recurring per-seat Stripe Price. A purchase is a Stripe subscription whose line-item quantity = N — a “quantity pack” is quantity N and a single seat is quantity 1 by the same mechanism. Because every pool is a subscription:

• it carries a term and expires;
• it renews when the Stripe invoice is paid;
• it lapses on cancellation.

The licence-pack product runs parallel to the existing tenant-tier subscription, resolved into its own grant path. The tier checkout is untouched by the pool checkout.

A pool’s status follows an append-only lifecycle: Active → PastDue → Cancelled. PastDue is the renew-ahead / grace condition (see Graceful degradation); it is not a kill switch.

AI credits

AI usage is metered in credits. Each paid tier includes a monthly AI-credit allowance, and one-off pay-as-you-go packs can be bought on top of it. As an order of magnitude, roughly 1,000,000 credits correspond to one standard AI action. Consumption is metered and enforced: an organisation that exhausts its allowance and packs cannot invoke further AI actions until the allowance renews or a pack is purchased. Credit state never touches plant control — AI is advisory-only either way.

Who issues, who enforces

The account control plane is the licence master — it holds the signing key and is the sole issuer. The cell mediates issuance and consumption; the site and edge enforce what was issued. The account never becomes the runtime enforcer.

flowchart LR
  Stripe[Stripe subscription] --> Account[Account control plane<br/>allocate + sign]
  Account -->|seat / signed artifact| Cell[Cell mediates]
  Cell --> Site[Site server enforces]
  Cell --> Edge[Edge runtime enforces]

The assignment authority — who may request and assign a seat — is the organisation’s own owner or admin (see Roles), bound to that organisation. The issuance authority — who cryptographically signs — is the account control plane. These are separate concerns: the cell admin surface validates an organisation-scoped admin against the route’s organisation and forwards to the account; it never self-issues.

Platform-admin is not the licence authority

A platform-admin identity (a verified @consystence.com identity, or a seed-list entry) is an audited operational bypass, not the licensing authority. Licence assignment is an organisation owner/admin concern; licence signing is the account control plane’s. Platform operators do hold an audited comp/support path — they can grant provisioning entitlements and issue site-activation codes — but they are never the signing authority (the account signer) or the customer assignment authority (the organisation owner).

Activation

Server identity is provisioned, not hardware-derived

A server’s licence binding is a provisioned identity — a registration secret written once at registration and persisted — not re-derived from hardware each boot. This replaces the older hardware-fingerprint model (motherboard serial, CPU ID, MAC), which broke on every snapshot/clone/migrate.

Activation codes: the customer flow

An organisation owner first declares the site on the tenant’s Sites page in the account console — declared sites are capped by the organisation’s tier — then generates a one-time site-activation code against that declared site. The code is shown once, expires in 7 days, and works once. The installer pastes it into the on-prem site server, which relays it through the cloud cell to the account; the account redeems the code, assigns a pool seat, and returns a signed activation bundle — the redeeming server joins the declared site. Platform operators can also issue a code as an audited comp/support path. (Trial tenants cannot mint activation codes.)

Online activation

Under the hood, the cell calls the account to assign a pool seat to an install — an idempotent, organisation-keyed consume. The install then holds a seat from the pool. No new cryptography is involved in the online path; it is allocation only.

Offline verification: the signed artifact

Once activated, an install needs no live call to the account to stay licensed. The account issues a signed, offline-verifiable licence artifact binding a pool assignment to the install. The site receives it inside the activation bundle, persists it, and verifies it fully offline thereafter — so the cell, site, and edge stay licensed through a network partition.

Fully air-gapped transport is roadmap

Fully air-gapped sites — where the activation artifact moves over removable media rather than a connected cell — are on the roadmap. Today’s flow assumes the installer can redeem the activation code through a connected cell once; after that, verification is fully offline.

Graceful degradation

A licensing condition never stops a plant

Licence expiry, lapse, or revocation degrade a server — they never kill control. The licence boundary sits at the engineering/configuration surface. It is never placed at the operator-control surface: Start, Stop, Reset, setpoint writes, and alarm acknowledgements are never gated by licence state. Gating an operator command would itself be the safety event this rule exists to prevent.

A licence is an expiring entitlement the server must hold to function, but failure is bounded:

• Renew-ahead when online, plus a grace window of roughly two weeks to one month, plus escalating, loud warnings as the window elapses.
• At the hard limit the server degrades to constrained, it does not stop the scan loop. Constrained mode gates only licence-consuming expansion — creating a new site or a new device instance. It does not block operator command writes or acknowledgements, and it never stops the running plant. (In the current build, constrained-mode enforcement itself sits behind an operator-enabled gate — until it is switched on, an elapsed grace window warns loudly rather than gating expansion.)
• There is no instant remote kill for an air-gapped server. Revocation is non-renewal at next contact; the lever is the expiry length, stated up front rather than discovered in an incident.

Subscription lapse and tenant suspension

Degrade-not-kill governs the site server’s control surface. It does not extend to the hosted cloud tenant, whose reachability follows its own subscription — each paid tenant carries its own Stripe subscription:

• PastDue is the grace state: the tenant stays up and routable, but the organisation cannot start a new tier checkout while any of its subscriptions is PastDue. (A Cancelled subscription does not block new checkout.)
• Cancellation suspends that tenant only — the organisation’s other tenants are untouched. A suspended tenant is immediately non-routable — the portal bounces to the organisation list with a tenant-suspended notice.
• A successful payment (or reactivating the subscription) restores the suspended tenant.

An on-prem site server keeps running through all of this: suspension makes the hosted cloud workspace unreachable, it never touches plant control.

Clock integrity

Expiry needs a trustworthy clock on a box that may be offline, so a clock rollback can never revoke a licence. A backward wall clock — from an RTC-battery failure, a snapshot restore, or an NTP correction — never shortens a licence or shuts a plant down; a rollback can only ever be safe.

Decommission

Decommissioning an install returns its seat to the organisation’s pool, freeing it for reassignment. Seat reclaim reconciliation is part of the same lifecycle. This is roadmap — seat release on decommission is not yet built.

Status: what is live today

Capability	State
Organisation tiers (Basic + the Integrator and Enterprise families), Stripe checkout + sales-led request → approve	Built, pre-GA
Stripe per-seat SKU pools (SiteServer / Edge / Agent)	Built, pre-GA
Self-serve organisation signup + sandbox provisioning	Built, pre-GA
Account-side licence signer	Built, pre-GA
Signed offline-artifact issuance + verify/consume (cell/site/edge)	Built, pre-GA
Cell-mediated online seat assignment	Built, pre-GA
One-time site-activation codes (owner console + operator comp path)	Built, pre-GA
Provisioned-identity binding	Built, pre-GA
Degrade-not-kill + clock-rollback safety	Built, pre-GA
Seat release on decommission	Roadmap
Fully air-gapped activation transport	Roadmap

For the surrounding model see the platform overview, the organisation & site model, authentication, and the cell topology. The admin surfaces that drive these flows are documented in the API reference.