Packages and licence tiers

CID222 is sold as three packages: Starter, Professional and Enterprise. There is one release image and one container stack; the signed licence file you upload decides which package the appliance runs as.

The problem

A capability model that lives in a sales document drifts from the code within a release. The question "does this customer have Code Safety?" then has two answers, and the one the customer experiences is whichever guard happens to be on the route. CID222 answers it in exactly one place — a typed map from capability key to the controllers and dashboard pages that key switches off — and generates the customer-facing table from that map.

How CID222 does it

Three packages, strict supersets

Moving up a package is a licence re-issue, not a reinstall: the same appliance, the same installation identity, the same data. medium is accepted as an alias for Professional on older licences.

The exact capability key each package grants, and what a missing key switches off — which controllers answer differently, which dashboard pages disappear — is generated from the code in licence tiers and feature keys. Read that table as authoritative; any package comparison written by hand is a snapshot.

How an entitlement is resolved

The appliance grants the union of the capabilities named in the licence file and the capabilities of the licence's tier. The union only ever widens, and that is deliberate: a capability added to the product after your licence was signed activates for you without a re-issue, instead of the module you already paid for going dark on the day a new key shipped. A bespoke capability list still wins wherever it is wider than its tier; where it is narrower, the tier decides, because the tier is the package that was sold.

Both halves are visible on Settings → License: the file's own capability list next to the resolved entitlements, so the widening is auditable rather than mysterious.

What a missing capability looks like

• The dashboard page is not there. Page access is filtered by capability, so an unlicensed page is absent from the navigation and refused by URL. A superadmin is exempt from the role table but not from the licence: a superadmin of a Starter appliance is still on a Starter appliance.
• The API answers 403 with the code FEATURE_NOT_LICENSED, worded as a statement about the package rather than about the reader's permissions.
• The licence, the settings and the update pages are never hidden, so the appliance can always be re-licensed and repaired.

The trial

An appliance with no licence installed runs a built-in trial: 30 days by default (CID_TRIAL_DAYS), at the Starter capability set (CID_TRIAL_TIER), counted from first boot rather than from the date the image was built. The trial is a working product, not a demo mode. It does not unlock Professional or Enterprise capabilities — ask your CID222 contact for a time-limited licence at that tier to evaluate them.

When the trial elapses, the product paths answer 402 with the code LICENSE_EXPIRED while sign-in, the dashboard, the licence page and the update page stay available. The procedure for turning a trial into a purchased package is licensing and activation.

Seats

A licence may carry a seat cap. It counts active accounts, and it refuses the creation of a new account with LIMIT_EXCEEDED once reached — during LDAP synchronisation as a per-user skip with an operator warning. It never blocks a sign-in: an existing user over a cap still gets in, because a billing dispute must not lock a company out of a product it has already deployed. Deactivated accounts are not counted, so removing a leaver frees a seat while keeping the audit evidence that references them.

Limits and known gaps

• Some keys gate nothing by design. Chat, proxy, OCR, document analysis, redaction, the MCP server and prompt compression carry no controller or page of their own — they are the product or a pipeline stage inside it, reached through endpoints other keys already cover. Expiry still blocks them.
• The installation binding is often soft. A licence is bound to an installation identity. Where the host tooling generated that identity, the binding is a hardware fingerprint; on a plain container deployment the appliance falls back to a random identity in a copyable file, and a virtual-machine clone presents the same one. The appliance reports which it has, and the activation request tells the issuer before signing.
• An expired appliance and a never-licensed appliance show different navigation. An appliance whose licence lapsed keeps the shape it was sold — its pages are one upload away from working. An appliance that never had a licence shows what a trial offers. Both are blocked from the product paths identically; only the navigation differs, and it is a chosen behaviour rather than an inconsistency.
• The testing lab is hidden on every licensed build. It answers 404 unless licensing is disabled or CID_ENABLE_LAB is set. It is a build-visibility switch, not a capability any package grants.
• Capabilities are not per-tenant. A licence entitles the appliance. There is no way to sell one department Enterprise and another Starter on the same deployment.

Related

• Licence tiers and feature keys — the generated table, regenerated from the code each build.
• Licensing and activation — export an activation request, upload a .lic file, renew or upgrade.
• Requirements and sizing — what to allocate per package before importing the image.