# Licensing

> Capabilities are feature flags carried by a signed platform licence and a plan, and an organisation's effective set is the intersection - checked at the route, not in the interface

Source: https://aipril.dev/docs/platform/environments/licensing

## Features, not editions

Capability is expressed as **feature flags**, not as product editions. A flag corresponds to a
block or a surface - analytics, processes, the ledger, pages, external plugin surfaces, and so on.

## Two sources, intersected

An organisation's effective feature set is:

**the features of its plan ∩ the features of the platform licence**

The platform licence is a signed token held by the installation. The plan is what the organisation is
entitled to within it. Neither alone decides: a plan cannot turn on something the installation is not
licensed for, and an installation licence does not grant every organisation everything.

One consequence worth knowing operationally: a licence issued before a feature existed does not carry
that feature. Adding a capability to an installation therefore means re-issuing the token, not only
changing a plan.

## Where the check happens

At the route, in the middleware - not in the interface. A hidden menu item is a cosmetic gate; here a
request for a feature the organisation does not have is refused by the server regardless of which
client made it.

So the product, the API and the MCP endpoint are all gated identically.

## Related

- [Deployment](https://aipril.dev/docs/platform/environments/deployment.md) - how an installation is updated.
- [Roles and grants](https://aipril.dev/docs/platform/access/roles.md) - what a licensed feature then lets a given person
  do.