The licensing lifecycle

A System9 license is a signed offline trust artifact, not a call home. An Ed25519-signed key, verified against a CA public key compiled into the build, whose private half never leaves an HSM, carries the organization's identity, its tier, its deployment posture, its entitlement limits, and its feature flags. From that one artifact the platform derives two independent things: what the cell may do (capabilities) and how the cell behaves as the license ages (enforcement). Both derivations run with no network, so the license works identically in the connected cloud and behind the air gap.

Two rules make the whole lifecycle safe to depend on:

• Overage is billed, never blocked. Exceeding an included allowance emits a billing sample; it does not refuse the request.
• The enforcement SDK never raises. A cap check returns a decision object; a service hot path translates a miss into a 402, never an exception.

This page is the arc from a signed key to a running, enforced cell, and the two ways capacity is bought over it, metered by default, or prepaid per node. For the identity the license is issued to, see the entity model; for how metered work becomes a verifiable bill, see Metering, FinOps & tokenomics.

License → capability → enforcement

Activation is the one chokepoint: a single builder registers the complete runtime key set, so no install path can leave the cell holding a subset of the license state. From the activated license, capability configuration and enforcement resolution proceed independently.

Figure L1: from a signed key to an enforced cell. The green stages are cryptographically verified (offline signature check, then the single activation chokepoint); the two derivations run independently from the activated license. The amber gate is where refusal can happen; a cyan included-overage is billed and the request proceeds, while a red hard-cap miss returns a 402. Ceiling: enforcement grading is implemented and wired; the operator-facing offline-status surface it feeds is owed.

Table equivalent

From	Relationship	To	Meaning
Signed license key	verified offline, then	Activate (one chokepoint)	verified (green): Ed25519 vs compiled-in CA key
Activate	derives	Capability tier mapping	Military only when the ITAR conjunction holds, else Enterprise
Capability tier mapping	configures	Capability registry	holds the tier, or None when unlicensed
Capability registry	yields	Enabled capability modules	the empty set when unlicensed (fail-closed)
Activate	derives	Ladder grading	expiry, offline-since-sync, and chain integrity all grade into one ladder
Ladder grading	resolves to	Permission-bit assignment	the single place every permission bit is set
Permission-bit assignment	drives	Born-enforced write gate + cap check	refusal happens here (amber)
Gate	on included overage	Overage accountant	billed, request proceeds (cyan)
Gate	on hard-cap miss	402 response	denied; "activate to unlock" (red)

Capability tiers

There is deliberately one rung per issuable tier, and no lesser third rung. A cell with no valid license holds no tier, represented as none, which resolves to the empty set of capability modules. Fail-closed is the default, not a mode.

Tier	Granted when	Adds, cumulatively
(none)	no valid license	nothing: the empty module set
Enterprise	any valid license that is not a qualifying military license	the base modules plus the enterprise security modules
Military	a military license and a sovereign or tactical posture and an ITAR-eligible class: the ITAR conjunction	everything Enterprise has, plus the defense modules

Tiers are cumulative: Military includes everything Enterprise grants, which includes the base modules that are always on for any licensed cell. A military license that fails the ITAR conjunction does not fall to nothing, it maps down to Enterprise (a commercial-defense posture), because a signature that verifies is still a real entitlement.

Capability modules are grouped by the tier that unlocks them:

• Base (every licensed tier): detection, alerting, compliance, posture, event ingest, and the security graph.
• Enterprise adds: behavioral analytics, data-loss prevention, orchestrated response, threat intelligence, supply-chain assurance, agents, and the advanced network-defense modules.
• Military adds: cyber operations, counter-threat, red-team and adversary modeling, self-healing, battlefield operations, tactical-edge, and radio integration.

The tier is a capability axis and is not the ITAR gate itself: ITAR-gated routes are enforced independently on every request. Deployment posture (commercial, sovereign, tactical) is a third axis again, independent of tier.

Entitlements: the short-lived offline grant

The license is the durable artifact; between check-ins, enforcement rides on a short-lived, Ed25519-signed entitlement token. It carries the tier, features, limits, a validity window, and a monotonic epoch so a token cannot be replayed after it is superseded. The token has its own temporal states, not-yet-valid, valid, grace, expired, classified purely from its window, and it is audience-bound: the token's organization must equal the deployment's organization or enforcement drops to the pre-license posture. A monotonic epoch ratchet, scoped per deployment organization, defends against clock rollback: a token from an epoch below the ratchet floor is refused.

The four-stage expiry ladder

Nothing goes dark on day one. Expiry is a single degradation ladder for the whole platform, and a license carries its own grace and read-only windows (30 days and 30 days by default). The doctrine is fixed in three phrases: born enforced (no entitlement is the pre-license Provisional rung, never fail-open), degrade the workload, never the senses (reads, export, and the essential internal writes (audit, telemetry, attestation, metering) stay on in every state), and never brick (Grace keeps workloads running and blocks only new provisioning).

Figure L2: the expiry state machine, read left to right as severity climbs. Provisional (amber) is the pre-license rung a cell is born into; Active (green) is full function; Grace (cyan) is the never-brick rung that keeps workloads running; Read-Only and Suspended shed function while the senses stay on. Three graders, expiry, time-since-sync, and audit-chain integrity, each grade into this one ladder and the most severe wins; a grader can only escalate, never relax. Ceiling: windows are per-license (30/30 by default); a license may set a zero grace window for a hard-stop trial.

Table equivalent

State	Reached when	Writes	New resources	Compute	Reads / export / essential writes
Provisional	no entitlement yet	no	no	no	always yes
Active	a valid license is active	yes	yes	yes	yes
Grace	past expiry, within the grace window	yes	no	yes	yes
Read-Only	grace window elapsed	no	no	no	yes
Suspended	read-only window elapsed, or revoked	no	no	no	yes (admin + export)

The essential-writes floor (audit, telemetry, attestation, and metering) is not tunable: no state can turn it off. That is what "degrade the workload, never the senses" means in the permission bits.

Installing, renewing or rotating a key

This page is the model. Applying a license is the operational half: the five install paths, what each rejection code means, how a renewal fans out across a node's cells, and how all of it works air-gapped.

For the second grader in the ladder above, time since the last verified sync, and what happens across a long disconnection, see when the meter cannot report.

Overage is billed, never blocked

Included allowances (included_* limits) define what the base plan covers. Exceeding one is billed, not refused. The overage accountant reads durable consumption totals, advances a high-water mark first so a concurrent writer cannot double-bill, and only then emits the billable delta as a usage sample on a cost-bearing dimension; pricing is attached downstream by rate cards. An included limit of zero means unlimited, no charge. By construction, edge-origin work contributes zero compute units, so it can never push an organization into overage.

Infrastructure count is free on every axis: cells, nodes, and service groups are unlimited and unmetered. You are never charged for the shape of your deployment, split into twenty cells across five regions for residency and resilience and the topology costs nothing; only actual work does.

The enforcement SDK never raises

Usage caps are enforced by a check that never throws. It returns an outcome object, allowed or not, with what was used, the limit, and, when denied, a ready-made 402 problem-detail body, so a service hot path is never forced to handle an exception on a cap miss. The rules it applies:

• No license → fail-open (development and test), so an unlicensed dev cell is not bricked by the cap layer; enforcement of the ladder still governs writes.
• License present, no hard cap for the resource → allowed; any included overage is billed downstream, not blocked here.
• A hard cap is set and exceeded → the outcome is not allowed with a 402 whose remediation points to activation, not to an upgrade page, both tiers are arranged with you directly.

Reported used and limit values are only ever what was actually measured; the check never fabricates a zero. In a multi-cell estate the check consults an authoritative global counter through a proxy first and falls back to the local counter, so a hard cap is a fleet-wide ceiling rather than a per-cell one.

Two ways to buy capacity: metered by default, or prepaid per node

Consumption is denominated in compute units (CU), the internal unit of account, cost_units in the meter. There are two purchasing shapes over the same metering, and a deployment can use either:

• Metered by default (organization post-paid). The default. Work accrues CU against the organization's included allowances, and an overage is billed, not blocked (above). This is the model the rest of this page describes.
• Prepaid capacity blocks (per node). A node can instead hold a prepaid block of capacity, a fixed quantity of CU purchased ahead of use, sized to the node. Blocks come on a ladder from a small base block up through a doubling progression to the largest (roughly a 1→2048 range of capacity), and a capacity sizer recommends a block from an expected workload. A node draws down its block as it works; a block is a per-node ceiling, not an organization-wide one.

Prepaid blocks are built for the sovereign and disconnected corners: grading runs offline and air-gapped, so a node knows how much of its block remains with no call home, and a block's cap can be lifted live ("hot cap-lift") without restarting the node when a workload needs more headroom. As everywhere on this page, edge-native inference is off-meter by policy, edge-origin work draws no CU against either shape.

Figure L3: the two purchasing shapes over one metering. Work is denominated in compute units; an organization can run metered (post-paid, overage billed) or a node can hold a prepaid capacity block off a sized ladder, drawn down as it works, with a hot cap-lift and offline/air-gapped grading. Edge-native inference is off-meter by policy under either shape. Ceiling: CU is the unit of account, not a cost of goods; no money moves in the platform, pricing and settlement are attached downstream by rate cards (see Metering, FinOps & tokenomics).

Table equivalent

Shape	Scope	How it is paid	Draw-down
Metered (default)	Organization	Post-paid; overage billed, never blocked	Accrues against included allowances
Prepaid capacity block	Per node	Bought ahead off a sized ladder	Node draws its block down; cap can be lifted live
Edge-native inference	Either	Off-meter by policy	0 CU: never draws from either

Across the deployment matrix

Every derivation on this page runs offline, which is what lets the license hold across the full single-cell/multi-cell, cloud/air-gapped matrix:

• Sovereign / air-gapped. Verification uses only the compiled-in CA key; the entitlement token carries the offline grant between check-ins; an air-gap addendum extends the offline window, and a wall-clock retreat forces Suspended rather than silently trusting a rolled-back clock. Signed offline metering bundles carry usage back out without a live connection.
• Multi-cell. A fleet projection materializes the same ladder from stored license state without probing thousands of cells, it composes the same grading primitives rather than re-implementing them, and is a deliberate lower bound (it never reports a degraded cell as healthy). Metering is delivered through a proxy, and a cell's identity key is derived, so a failover is not misread as a key rotation.

Design status

Capability tiers, the license-to-capability mapping, entitlement tokens, the four-stage ladder, overage accrual, the never-raising cap enforcer, and the per-node prepaid capacity-block model (the block ladder, the capacity sizer, the hot cap-lift, and offline/air-gapped grading) are all implemented; the overage accountant and cap enforcer are additionally wired into the live meter-flush and request-enforcement paths. The offline-status surface that the grader feeds is owed work, the grading itself is done.

In the console and portal

Licensing has surfaces on both administration surfaces.

In the operator console, the node license lives at /settings/license and the fleet rollup at /admin/org/licenses, both gated on org.license.read. The node page shows the entitlement, the enforcement state as a text-and-glyph badge over the same five-stage ladder this page describes (provisional → active → grace → read_only → suspended, never colour alone), a per-cell enforcement rollup, the telemetry / phone-home posture, and usage-versus-included bars. Applying a key uses a two-phase validate then apply dialog: a verify-only decode first, then the session-authed apply. The fleet page is exceptions-first, summary tiles (cells, nodes, needing attention, expiring, offline, revoked) over a fleet-exceptions table.

In the administrator portal, an org sees its own licenses at /licenses and /licenses/[id] (org-scoped), including the raw signed s9lic artifact and the air-gap addendum; resending a signed license to the billing address is a billing-role action (canManageBilling) and is audit-logged.

The portal entitlement gate is not load-bearing

The portal can derive feature visibility from a license class (show / tease / hidden) through its capability-manifest mechanism, but that gate is built and tested and not wired into any portal page yet. See Administration & Configuration.

Related topics

• Applying a license, the install, renewal and rotation procedures.

• When the meter cannot report, the offline ladder and metering behaviour across a disconnection.

• Administration & Configuration, the console and portal surfaces, and how config deploys.

• Metering, FinOps & tokenomics, how metered work becomes a verifiable, offline-provable bill.

• The entity model, the organization identity a license is issued to.

• The entity lifecycle, how the entities that consume capabilities are created and provisioned.