aipackage/specs/001-enterprise-experience/contracts/offline-license-policy.md

Zero-Network License and Activation Policy

Status: Approval draft; no implementation authority.

Goals

Nexus One AI licensing MUST be independently verifiable with no network, distinguish product category from Server tier, preserve customer data through license-state changes, and never convert missing, invalid, expired, time-uncertain, revoked, or machine-mismatched material into a valid entitlement.

Release artifact signatures and customer license signatures are separate trust domains. The current RSA-SHA256 cezen.license.v2 format remains compatible until an approved migration changes it.

Observed Existing Behavior and Gaps

• The canonical evaluator verifies RSA-SHA256, issued_at, expires_at, optional machine binding, tier and feature overrides locally.
• A missing license returns field-staging, needs_activation: true, and compatibility tier basic.
• Invalid signatures, future-issued, expired, and machine-mismatched licenses are not valid, but their normalized allowed_tier can still remain available to surrounding code unless every consumer also honors valid/staging_only.
• Machine binding is enforced only when the caller supplies machine_id; current CLI flows can omit it.
• No signed offline license-revocation list, trustworthy-clock state, backward-clock detection, or durable last-known-good license-evaluation time is defined.

These are planning blockers. A basic compatibility default is not evidence of a Server M entitlement, and an omitted machine ID cannot make a bound license portable.

Required License Envelope

A production signed license MUST declare schema/version, unique license ID, customer/project ID, product category (workstation or server), exact Workstation entitlement or Server tier ceiling, issued-at, optional not-before, expiry/support policy, feature overrides, machine-binding mode/value, license-policy version, signing-key ID, and signature algorithm/signature. Optional fields never weaken the default policy.

Customer-visible and diagnostic views expose only an allowlisted summary. Raw signature, license key, customer identifiers beyond approved display fields, and machine-binding source values are excluded from logs and support exports.

Offline Import and First Activation

1. Import from approved removable media or local browser/console input; copy to a protected staging path and never execute content from that media.
2. Parse size-bounded canonical JSON and reject duplicate keys, unknown critical fields, unsupported schema/algorithm, malformed dates, and invalid category/tier combinations.
3. Verify the license-signing key and signature using the embedded approved license trust store.
4. Resolve a stable device identity locally and evaluate binding whenever the license declares one. Failure to obtain the identity is binding_unavailable, not a binding bypass.
5. Evaluate trustworthy-clock state, issued/not-before/expiry, offline revocation policy, product, hardware/provisioning constraints, and feature overrides.
6. Display the exact resulting state and allowed actions before activation.
7. Persist the signed license atomically with root-owned least-privilege permissions, record only a redacted audit summary, then re-evaluate from the persisted copy.

No online activation callback is required for a license designed for offline use.

License States and Behavior

State	Meaning	Required behavior
valid	Signature, policy, time, revocation, category/tier and binding pass	Enable only licensed + provisioned + hardware-supported + healthy capabilities
missing	No license supplied	Enter explicit field-staging mode only when operator chose it; never infer a purchased tier
invalid_signature / unsupported	Untrusted or unreadable artifact	Reject import; do not alter active valid license or entitlement
not_yet_valid	Trusted license before allowed start	Preserve existing valid entitlement if applicable; otherwise restricted/staging state
expired	Trusted license beyond expiry policy	Preserve data, backup/export and license replacement; restrict gated operations per approved expiry matrix
machine_mismatch	Bound identity differs	Reject activation; preserve existing valid license; provide redacted device/support reference
binding_unavailable	Required identity cannot be derived	Fail closed for activation; allow local diagnostics/retry
revoked	License ID or signing key is on trusted offline revocation data	Enter restricted recovery-safe state; never delete data/models
clock_uncertain	Current time cannot be trusted sufficiently	Do not newly activate a time-bounded license; preserve safe existing state per continuity rule
clock_rollback	Clock moved behind durable last-known-good evaluation beyond tolerance	Block new activation/renewal and gated mutations; require authorized clock recovery

Field-Staging Contract

Field staging is a deliberate installation state, not a free Server tier and not a fallback for an invalid license. It permits only the approved staging allowlist needed to configure network, inspect hardware, import a license, validate artifact identity, view local help, collect redacted diagnostics, perform backup/export, and prove core readiness.

General customer AI use, tier-gated Server capabilities, optional model packs, production data import, and update actions above the staging maintenance allowance remain disabled unless a valid signed license or separately signed time-bounded evaluation license authorizes them.

The current STAGING_MAX_TIER=basic remains an internal compatibility value only and MUST NOT be used as authorization. Product/security owners must approve the staging capability allowlist, duration, evaluation-license process, and whether an unsigned staging install may persist indefinitely in a non-production restricted state.

Clock Confidence Without Network

The appliance records UTC reading, clock source/confidence, boot ID, and the highest trusted license evaluation time in tamper-evident local state. It compares RTC/current time with signed license dates, signed update/build times, and last-known-good evaluation. NTP is helpful but never mandatory.

• A normal forward clock continues evaluation.
• A small approved tolerance accommodates RTC drift; the exact tolerance requires security approval.
• A backward move beyond tolerance becomes clock_rollback.
• No trustworthy time on first activation of a time-bounded license becomes clock_uncertain.
• Manual clock correction requires an authorized local action and audit record.
• Changing the clock never changes a bad signature, revoked key/license, category, tier or binding.

Expiry and Continuity

Expiry MUST NOT erase customer data, uninstall services/models, invalidate backups, or prevent license replacement and recovery. The approved expiry matrix separately controls existing inference sessions, new sessions/jobs, data ingestion, model import, configuration, updates, user administration, backup/export, restore, diagnostics, and emergency security updates.

Recommended safe default: block new license-gated workload creation and commercial expansion while allowing read-only access, completion/cancellation of already-running safe work where feasible, backup/export, diagnostics, local help, and license replacement. Exact grace periods and emergency security-update rights require product/security/legal approval and MUST be encoded in the signed policy, not hard-coded differently by UI and backend.

Machine Binding

Binding modes are none, single_device, or an explicitly approved cluster/appliance mode. Device identity must be stable across reboot and ordinary service/OS updates, replaceable only through a signed rehost/recovery artifact, and derived without exposing raw serials in customer-facing evidence. The binding algorithm/version and hashed identity components are part of license policy.

Hardware replacement never silently adopts the old binding. The recovery process preserves data, produces a redacted old/new device reference, imports a signed rehost authorization or replacement license, and records the actor and result.

Offline Revocation and Trust Updates

A root-signed license trust/revocation bundle contains version, issued/expires policy, revoked license IDs, revoked signing-key IDs, reasons suitable for operators, replacement trust roots, and signature. It is imported through the shared trust-bundle mechanism and verified before replacing active policy.

Stale revocation data behavior must distinguish new activation from continuity of an already-valid installed license. Recommended default: block new license activation when revocation policy exceeds its approved maximum age; warn and preserve a currently operating non-revoked license until the approved continuity limit, while retaining backup/export and recovery. Exact ages require approval.

Interruption and Recovery

• Interrupted copy/parse/verification leaves the active license unchanged and staging quarantined.
• Interruption after atomic persistence re-evaluates the persisted artifact on reboot.
• A rejected replacement never overwrites an existing valid license.
• Trust-bundle interruption retains the prior trusted policy.
• Clock or binding recovery resumes the same durable activation operation.
• If entitlement decreases, stop new gated work first; do not corrupt in-flight work or delete data.
• License removal is authorized/audited and moves to explicit staging/restricted state; it never fabricates basic entitlement.

Evidence Gate

Test valid Workstation and each Server tier; deliberate staging; missing; malformed; duplicate-key; unsupported schema/algorithm; invalid signature; future-issued/not-before; expiry boundary; clock uncertain; backward clock; machine match/mismatch/unavailable/rehost; category/tier mismatch; feature override; revoked license/key; stale revocation policy; interrupted import/persist/trust update; license replacement; entitlement reduction; reboot persistence; and denied-role access. Verify every surface reports the same state and no raw license/binding secret enters logs or support evidence.

Owner Decisions Still Open

• Staging allowlist, duration and signed evaluation-license process.
• Expiry/grace/continuity matrix and emergency security-update rights.
• Device identity inputs, hashing/version, rehost authority and cluster binding.
• Clock tolerance, trustworthy-first-time procedure and authorized correction role.
• License revocation maximum age and stale-policy continuity limit.
• License signing-key custody/rotation relationship to the separate artifact-signing trust domain.