Skip to main content

Workspace billing add-ons — horizontal boundary surface

Tier: Public
Status: Contract documented; implementation deferred H1 2027 (accepted 2026-05-28)
Audience: module authors, billing integrators, hosted-service operators
Resolves: RFC-0009 — pre-implementation boundary
Related: RFC-0001 §8.2, PLATFORM-ARCHITECTURE.md §3.6–§7.4, ROADMAP.md Wave E-full / F-mod / item 2h; integrator gap doc BUILDING-YOUR-VERTICAL.md

Disclaimer. No WorkspaceBillingAddon Prisma model, Stripe subscription-item flow, or add-on enforcement ships in the July 2026 public-alpha tranche. This document exists so modules do not add parallel entitlement stores or payment integrations while registerModule({ addonCodes }) is already live.


1. Summary

LayerOwnerStatus
Base subscriptionplatform.WorkspaceBilling + tiersShipped
Tier numeric capstierLimitsService + module tierLimits slicesShipped
Add-on declarationregisterModule({ addonCodes }) + boot collision checkShipped (this RFC)
Add-on persistenceplatform.WorkspaceBillingAddonPartial (F-mod Phase 3, 2026-05-31) — Prisma model + EntitlementsService query path; Stripe/RevenueCat wiring still H1 2027
Add-on enforcementEntitlementsServicetier_only default; opt-in ENTITLEMENTS_ENFORCEMENT_MODE=tier_and_addons
Managed-AI creditsmanaged_ai_credits_* add-ons + pricebookDeferred (ROADMAP E-full)

Public alpha MAY ship without purchasable module add-ons; it MUST NOT ship without this boundary (RFC-0009 Decision E).


2. Declared add-on codes (v1 registry)

Codes MUST be declared on exactly one module via registerModule({ addonCodes: [...] }). Boot fails on duplicates (AddonCodeAlreadyRegisteredError).

addonCodeDeclaring moduleNotes
brewery_modulebrewery (tier-6 vertical)Reference vertical; bundled in α tier story
automation_moduleautomationFirst likely enforcement target (H1 2027)
pim_modulepim
mrp_modulemrp
crp_modulecrp
managed_ai_credits_*(platform-reserved)Not sold until E-full; pattern reserved in RFC-0009

Third-party modules use <code>_module under their own module code per third-party module guide.


3. Enforcement modes

ModeWhenhasActiveAddon() behavior
tier_onlyPublic α through pre-implementationAlways true (no DB lookup)
tier_and_addonsAfter H1 2027 implementationQuery WorkspaceBillingAddon; require status === active

Implementation: services/api/src/services/entitlementsService.ts.

Call-site discipline: Modules SHOULD NOT add hard assertAddonEntitled gates until enforcement mode flips — tier limits remain the α enforcement surface. Automation surface doc "enforce on vessel create" is aspirational until H1 2027.


4. Tier vs add-on matrix (conceptual)

Example for automation (illustrative — not enforced in α):

GateTier limitAdd-on
Max vessels / adapterstierLimits(tier)
Paid automation surfaces (future)Requires premium+ (platform)Requires automation_module active row

Both checks may apply once implementation lands. Neither replaces the other.


5. H1 2027 implementation checklist (backlog)

#StepRepo
1Prisma WorkspaceBillingAddon in platform.* + forward migrationumbraculum-dev
2Stripe subscription-item create/update on purchase; webhook handlersservices/api
3RevenueCat entitlement mirror (native)services/api
4Flip EntitlementsService to tier_and_addons on hosted profileservices/api
5First enforced routes (candidate: automation vessel/adapter create)module + platform
6Admin/operator UI for workspace add-onsapps/web
7Managed-AI credits (E-full) — optional same tranche or successorplatform AI orchestrator

Backup discipline for billing DDL: same as platform-brewery-postgres-schema-split.md §3 (pg_dump -Fc before migrate).


6. Self-host

ProfileBehavior
Hosted (production)Enforce purchased add-ons once step 4 lands
Self-hostConfig may grant all add-ons or skip checks (RFC-0009 Decision F)

7. References


Accepted boundary 2026-05-28. Implementation PRs should link this doc and RFC-0009.