Skip to content
Kisum • Documentation

Commercial Model (Permissions & Packages)

Related documentation: Permissions Blueprint · Permissions Catalog · Backend Core Packages · Backend Core Modules · Backend Core Addons

Design-Only Commercial Blueprint

Section titled “Design-Only Commercial Blueprint”

This document is intentionally limited to:

  • packages
  • modules
  • add-ons
  • permission relationship
  • delegation relationship

It does not describe current implementation status.

1. Commercial structure

Section titled “1. Commercial structure”

1.1 Base modules

Section titled “1.1 Base modules”
  • promoter
  • artist
  • vendor
  • venue

1.2 Add-ons for a base module

Section titled “1.2 Add-ons for a base module”
  • finance
  • ai
  • touring
  • venue_marketplace

2. Core commercial rule

Section titled “2. Core commercial rule”

The commercial model must be read in this order:

Base module / add-on
-> enables capability eligibility
-> enables module eligibility
-> makes permission families commercially possible
-> user still needs Auth grants

This means the platform must separate:

  • what a company bought
  • what a user can access
  • what a user can grant to others

3. Company versus user

Section titled “3. Company versus user”

3.1 Company level

Section titled “3.1 Company level”

Company level decides:

  • what the company bought
  • which modules are enabled
  • which add-ons are enabled
  • which permission families are commercially possible

3.2 User level

Section titled “3.2 User level”

User level decides:

  • what modules the user may access
  • what permissions the user may use
  • what scope restrictions apply
  • what the user may delegate to others

4. Package, module, add-on, permission, delegation chain

Section titled “4. Package, module, add-on, permission, delegation chain”
Base module / add-on purchase
-> company commercial entitlement
-> module eligibility
-> permission-family eligibility
-> user grant
-> scope restrictions
-> delegation limits

Every team in the platform should understand this chain.

It is the core rule that keeps commercial logic and access logic separated.

5. Basic package model

Section titled “5. Basic package model”

The Basic package is the main operational package.

It should be treated as:

  • one commercial package
  • backed by one basic capability domain
  • compatible with specific add-ons
  • the main operational entry point for companies

It is the main product bundle for companies that want operational planning, artist intelligence, event management, workspace tooling, and market support features.

6. Standalone module model

Section titled “6. Standalone module model”

Finance, AI, Touring, Market, and Venue Availability are different from Basic add-ons because they can be purchased alone.

This means:

  • they are not dependent on Basic
  • they must have their own module identity
  • they must have their own permission families
  • they should not be documented as “just advanced add-ons”

7. Add-on model

Section titled “7. Add-on model”

Add-ons are optional commercial enhancements to an existing product path.

Current add-ons:

  • Vendor directory
  • Venue directory
  • Live ticket sales
  • AI report over sales for marketing campaigns

These should be treated as:

  • optional
  • explicitly compatible
  • commercially meaningful
  • not direct user permissions by themselves

8. Permission design rule

Section titled “8. Permission design rule”

Permissions must never be defined directly from package names.

Use:

  • package -> commercial availability
  • module -> permission namespace
  • permission -> actual user action

Good examples:

finance.income.read
finance.expenses.write
market.contracts.read
venue.availability.read
basic.events.create

Bad examples:

basic-package-user
premium-package-editor
finance-addon-person

9. Delegation rule

Section titled “9. Delegation rule”

Delegation is not the same as permission.

Permission answers:

What can this user do?

Delegation answers:

What can this user grant or manage for another user?

Example:

  • user has finance.write
  • but delegation may still forbid them from granting finance.write to someone else

10. How to create future commercial products

Section titled “10. How to create future commercial products”

10.1 Create a new package when

Section titled “10.1 Create a new package when”
  • the product is a real commercial tier
  • module composition differs
  • add-on compatibility differs
  • the target customer profile differs clearly

10.2 Create a new module when

Section titled “10.2 Create a new module when”
  • the capability is a real product boundary
  • it needs its own permission namespace
  • it may be sold independently

10.3 Create a new add-on when

Section titled “10.3 Create a new add-on when”
  • the capability is optional
  • it enhances an existing package or module
  • it does not deserve a full standalone module identity

10.4 Do not confuse catalog layers

Section titled “10.4 Do not confuse catalog layers”

Do not:

  • create a package when a price list would solve the problem
  • create a module for one tiny feature
  • create an add-on for something that should always be included

11. Summary

Section titled “11. Summary”

The platform commercial model must stay clean:

  • packages are commercial bundles
  • modules are capability boundaries
  • add-ons are optional extensions
  • permissions are module-scoped user actions
  • delegation controls what users may grant to others

That separation is the rule that allows the platform to grow without breaking access governance.