URD: Licensing
| Module | Version | Updated |
|---|---|---|
CORE-15 | v0.3 | 2026-07-15 |
What the Licensing module does
Defines the user-facing requirements for Plans & Licensing - so platform operators can control exactly what each merchant is entitled to run, merchants can self-serve a free trial, and every other service in the system can enforce features and device seat quotas offline against a trustworthy signed certificate.
The module keeps two layers separate. A plan is a reusable template - trial, subscription, or perpetual - defined once by an operator. A license is the concrete entitlement, issued from a plan and bound to exactly one merchant or user. Many licenses can be issued from the same plan.
Five things to understand first
This is the most important part of the document. Understanding the five ideas below covers 80% of the module.
1. A license always comes from a plan
No license is ever hand-built from scratch. An operator first defines a plan - carrying a type (trial / subscription / perpetual), a duration, an optional grace period, a device seat limit, and a bag of typed feature flags. When a merchant or a user needs an entitlement, the system issues a license from exactly one of those plans, with a unique key. A merchant can also self-serve a single free-trial license without an operator's involvement.
2. A license moves through a guarded lifecycle
A license carries exactly one of four statuses: activated, suspended, expired, or revoked. Every transition is checked against the current status: suspend then reinstate, renew to extend validity. Renew is refused for a perpetual license, since there is no duration to extend. Revoke is terminal - a revoked license can never be renewed or reinstated again. Every lifecycle action is written to an append-only event log, and the license's certificate is re-signed right after.
3. A device takes one seat, never more
A license binds to specific devices through activation, identified by the device's fingerprint. Each unique device consumes exactly one seat within the plan's seat limit; a null limit means unlimited. Re-activating the same device reuses its existing seat, never a second one. Deactivating a device frees its seat for another.
4. Other services trust the certificate, not a live call every time
A service validates a license key once and gets back the status, the resolved feature set, device seat usage, and a signed certificate. Other services verify this certificate offline, so none of them ever calls the Licensing module on every request. A license past its grace period is not caught by an active background sweep - it only flips to expired at the very next validation.
5. The Operations team has its own admin surface in the Back Office
The engine behind the four ideas above runs behind the scenes. The Operations team needs a place to author subscription plans, view every merchant's licenses, and manage device activations platform-wide - this is the Operations team's admin surface on top of the licensing engine, not the merchant-facing entitlement experience.
What the module covers
Five feature areas. Click an AREA code to jump to the Details tab and read that area's requirements.
AREA | Name | Phase | Status |
|---|---|---|---|
PLN | Plans & Feature Flags | P1 | Built |
LIC | License Lifecycle | P1 | Partial |
ACT | Device Activation | P2 | Not built |
VAL | Runtime Validation & Entitlements | P1 | Built |
LADM | Licensing Administration (BO) | P2 | Partial |