Subscriptions and Entitlements
Status: settled product/architectural contract, 2026-09-16; commercial model added 2026-11-02 as intended future architecture. Commercial mechanisms, billing providers and runtime enforcement are not specified or claimed implemented here.
Current versus target implementation. Currently, all Businesses are treated as active. No subscription, entitlement, billing, Licensed/Guest or activation enforcement is implemented anywhere in the application (verified absent from app/ by source search, 2026-11-02). The commercial model, the Operational Gate and the inactive, never-activated and lapsed Business behaviour in this document describe the intended future architecture. No subscription-related restriction may be introduced into the current implementation or interfere with the Spearmint Design milestone; a build of the gate requires separate authorisation after the open decisions below are settled. See implementation status and PRR-063.
Owns: Business subscription requirement, the commercial model (what is charged and what is free), subscription state, operational entitlement, Licensed and Guest counting, the unsubscribed-Business experience requirement, activation, suspension and reactivation semantics. Product definition owns the product distinction; identity and governance owns authority and the User and Person definitions; workflows and automation owns operational execution semantics.
Commercial Model (Current Working Proposal)
Intended future architecture; not implemented.
- Only Business subscriptions are charged. User registration is free, Business creation is free, and Guest Users are free and never counted.
- A subscription is per Business. A Licensed User counts towards that Business's subscription once, and counts independently in each Business where the User is Licensed. Activity level, authority level and relationship type do not change the count.
- Licensed status determines only whether a User counts towards the subscription. It grants no operational authority: authority remains governed by Membership, AuthorityGrant and Policy under [identity and governance](identity-and-governance.md#licensed-and-guest-users). A Guest cannot execute Business operations, so an external participant who must perform one (for example a supplier updating dispatch status) must be Licensed.
- Classification is derived wherever possible and must not be duplicated as stored state. The derivation mechanism and edge cases are unresolved (identity open question 6).
Working pricing bands (the current commercial proposal, not a settled price list):
| Licensed Users in the Business | Monthly subscription | |---|---| | 1–30 | £199 | | 31–100 | £499 | | 101–500 | £1,499 | | 501+ | From £2,499, individually negotiated |
The bands are billing bands, not feature tiers, a tier catalogue, platform Types or an access matrix, and they confer no capability distinctions or authority (see Subscription State).
Pricing-transition rules are unresolved. Open: behaviour when a Business crosses a band threshold, notice, grace, timing and proration of changes, reductions, conversion of a Guest to Licensed, and activation of a Business that already has associated Users. No rule is inferred.
Independent Concepts
An active subscription is the normal operational entitlement for Business-scoped operation. Subscription/entitlement is not Business identity, ownership, authority, creator provenance, membership, a tenant relationship or administrator identity. Business identity, capability definitions and capability objects, retained configuration, knowledge, history and governance may exist before an entitlement is confirmed or while it is inactive; the entitlement determines which applicable operations and operational effects may proceed.
The User that created a Business, the Users that administer it and the entity that pays for or manages its subscription may be different. A Business subscription is attached to the Business, not to the User who created or administers it; creation provenance, administration authority, subscription management and payment responsibility remain separate concerns. This contract does not introduce a distinct Account, payer or agency object. Any commercial actor remains a separately approved product and identity decision. A Business may exist indefinitely without a subscription, and a User may be associated with a Business without payment.
A Business is not defined by whether one or many identities administer it, or by a commercial arrangement sometimes described as single-business, multi-business, agency or multi-tenant. Those descriptions do not create Business identity variants.
Subscription State
Subscription state determines whether the Business has the operational entitlement required for normal Business-scoped execution. The exact state vocabulary, billing process and provider integration remain future product and implementation work. At minimum, the architecture distinguishes active entitlement from inactive entitlement.
Changing subscription state does not create, transfer, restrict or revoke Business authority. Authority remains governed independently under identity and governance, and subscription state remains inspectable by appropriately authorised identities.
Subscription is one input to an operational or access determination, not a substitute for authority. Capability existence, permitted information, operation initiation, approval and execution remain separate conclusions derived from the relevant object, relationship, authority, Policy, entitlement and context. Do not introduce a subscription-shaped copy of capability state, a universal tier catalogue, a final access matrix or a remaining counter as semantic authority.
Derived Commercial Conditions
Intended future architecture; not implemented. Whether a Business is subscribed, unsubscribed, never activated or lapsed is derived from entitlement evidence and its history. It is never a stored subscribed flag or a combined lifecycle field, consistent with core object model and authority. Likewise, Licensed and Guest classification is derived wherever possible and introduces no duplicated state. The derivation mechanisms and edge cases remain open design work.
Unsubscribed Business and Promotional Preview
Intended future architecture; not implemented. An unsubscribed Business (never activated, or lapsed) keeps its identity and all retained information, and remains inspectable and governable within authority; only Business-scoped operational execution is gated (see Operational Gate). Two presentation experiences exist, and neither is authority:
- **Unsubscribed preview.** An unsubscribed Business may show a promotional dashboard that explains what activation would provide.
- **Guest Business presentation.** A Guest sees a Business through ordinary authorised inspection and presentation, not through promotional content.
Requirement: synthetic promotional or illustrative content must never become genuine Business data in the authoritative Business Graph, and must be labelled as illustrative wherever shown. The mechanism is unresolved. No storage mechanism or second data model is chosen here, and none may be assumed (PRR-065). Presentation owners (views and content) take only the requirement from this document.
Activation and Lapse
Intended future architecture; not implemented. Activation (first subscription) and lapse (loss of an active subscription) are changes of entitlement evidence, not creation or deletion of the Business. On lapse the Business remains intact under Suspension Retention. Activation and reactivation resume operation of the same Business without reconstruction. How activation treats Users already associated with the Business, and the count and price preview shown at activation, depend on the unresolved Licensed and Guest derivation and pricing-transition rules.
Suspension Retention
When a Business subscription becomes inactive, the Business remains intact. Retain its identity, data, Business Graph, Business DNA, models, configuration, workflows, knowledge, history, authority relationships and governance state. Suspension does not delete, reconstruct, transfer or revoke those things.
Appropriately authorised identities retain sufficient governance capability to inspect subscription state, manage or reactivate the subscription, administer subscription/billing matters where supported, and perform permitted governance operations. This does not define a billing system or grant authority that the identity does not already possess.
Operational Gate
Intended future architecture; not implemented. All Businesses are currently treated as active and nothing enforces this gate today. The normative invariant is:
> No Business-scoped operational capability may execute while the Business subscription is inactive.
This includes, where applicable, Business model use, Workflow Execution, Automation, scheduled or background execution, autonomous Business-scoped actions, external-triggered processing, integration-driven Business operations, model execution and other Business-scoped operational effects.
Authorization and operational entitlement are separate checks. An authorised request may inspect or govern an inactive Business, but it cannot execute a Business-scoped operational effect while the entitlement is inactive. A due schedule, queued work item, external trigger, integration callback or model output does not bypass this gate.
The gate does not prohibit retained history/configuration inspection or separately permitted subscription and governance actions. It does not apply to User registration or business.create, which are free and never entitlement-gated. It does not define a worker, queue, scheduler, billing provider or recovery engine.
Accordingly, an inactive or not-yet-confirmed entitlement may limit operational execution or deeper capability operations while leaving an appropriately authorised identity able to inspect permitted Business and capability information, understand what exists and manage governance or reactivation. The exact depth and commercial rules remain open product and governance work; this contract does not define feature tiers or a conventional paywall architecture.
Where an operation is unavailable because entitlement is inactive or unconfirmed, the product should explain that actual entitlement condition and any separate authority or configuration requirement. It must not erase Business identity, historical information, retained configuration or legitimate inspectability, or invent a duplicate lifecycle classification to explain the denial.
Reactivation
When the subscription becomes active again, the same Business, data, history, configuration, governance and authority relationships remain in place. Normal authorised Business-scoped operational execution may resume under the current authority, Policy and execution contracts. No reconstruction process is implied.
Boundaries and Conformance
- Conforming: a Business can be administered by a different User from its creator without changing Business identity.
- Conforming: an authorised subscription manager can restore an inactive subscription without becoming the Business creator or sole administrator.
- Conforming: an inactive Business remains inspectable and governable within authority while its operational workflow and model actions do not execute.
- Nonconforming: treating subscription payment as authority, treating Licensed status as authority, counting Guests, deleting Business data on suspension, revoking authority because entitlement is inactive, gating User registration or Business creation on entitlement, or allowing a scheduled or externally triggered Business operation to run during suspension.
Objects and types owns any approved typed representation. Time and events owns state-change history. This document does not prescribe fields, identifiers, billing workflows or physical storage.