Backend Core Modules

Related documentation: Backend Core Packages · Backend Core Addons · Commercial Model · Permissions Blueprint · Permissions Catalog

Module Catalog Design Specification

This page defines the module model only.

• a module is a product capability boundary
• a module is not a package
• a module is not an add-on by itself
• a module is the unit that permission families should attach to
• a module should remain stable even if packages change over time

---

1. Current module catalog from the platform definition

1.1 Base modules

These are the primary persona modules:

• promoter
• artist
• vendor
• venue

1.2 Add-on modules

These are optional capabilities layered on top of a base module:

• finance
• ai
• touring
• venue_marketplace

---

2. What a module is for

A module answers:

What coherent product capability boundary exists in the platform?

A module is the level where the platform should define:

• capability ownership
• permission namespace
• commercial eligibility boundary
• navigation boundary
• backend boundary over time

Modules are the layer between commercial catalog and user-level access.

---

3. Module definitions

3.1 basic

The basic module represents the core operational product surface.

Capabilities currently attached to this module:

• Artist data
• Artist data analysis
• Charts
• Industry contacts
• Availability tracking
• Booking system
• Events list and calendar
• Event creation tools
• AI market study for comparable tickets
• Event market-value estimation
• Estimated cost / P&L
• Estimated and actual financial reporting when applicable
• Workspace and task management
• News and updates
• Market data
• Festival ranking
• Upcoming shows and market value indicators
• Top promoters

Permission family examples

• basic.artists.read
• basic.events.create
• basic.tasks.manage
• basic.market-study.read

3.2 finance

The finance module includes:

• Expenses management
• Income management
• Ticketing management and reports
• Financial reports per event and company
• Agency and vendor dashboards for expense tracking

Permission family examples

• finance.expenses.read
• finance.expenses.write
• finance.income.read
• finance.bills.read
• finance.reports.read

3.3 ai

The ai module includes:

• AI model for market predictions
• AI research
• AI event-value estimation
• AI artist-value estimation

Permission family examples

• ai.predictions.read
• ai.research.read
• ai.valuations.read

3.4 touring

The touring module is currently marked TBC, but conceptually includes:

• Routing access for logistics teams
• Promoter and artist coordination workflows
• Travel coordination tools
• Accommodation coordination tools
• Operational touring workflows

Permission family examples

• touring.routes.read
• touring.routes.write
• touring.logistics.manage
• touring.coordination.manage

3.5 artist

The artist module includes:

• Artist and agency profile management
• Representation and roster workflows
• Availability, offers, and booking workflow
• Contracts, touring, logistics, and relationship intelligence on the artist side

Permission family examples

• artist.profile.view
• artist.availability.edit
• artist.offer.manage
• artist.contract.manage

3.6 venue

The venue module includes:

• venue and space management
• venue availability and booking workflows
• venue event operations
• venue-side contract and rental workflows
• venue-specific reporting and operational controls
• access to venue data and details

Permission family examples

• venue.availability.read
• venue.details.read

---

4. How modules should be designed

Every module must answer:

• what business surface it owns
• whether it is standalone or package-included
• which permission families belong to it
• whether it can appear in multiple packages
• whether it can accept add-ons
• whether it has scope-sensitive data

4.1 Every module needs a stable key

Good examples:

• promoter
• finance
• artist
• ai
• touring
• venue

Do not encode pricing, campaigns, or package names in module keys.

4.2 Every module should group permissions

Permissions should be namespaced by module.

Examples:

• finance.*
• market.*
• ai.*
• touring.*
• venue.*
• basic.*

This keeps permission design stable even when packages change.

4.3 Every module should have a clear product boundary

A module is appropriate when:

• it has a distinct business surface
• it has coherent permissions
• it may be sold independently or bundled meaningfully
• it can be explained to commercial and product teams clearly

Bad module boundaries usually happen when a team tries to model:

• one single screen
• one report
• one temporary feature
• one pricing idea

---

5. Base modules versus add-ons

5.1 Base module

A base module is the company’s primary product persona.

Current examples:

• promoter
• artist
• vendor
• venue

5.2 Add-on module

A standalone module can be purchased without the base package.

Current examples:

• finance
• ai
• touring
• artist
• venue_marketplace

5.3 Important rule

The platform must never confuse:

• a standalone module
• a package
• an add-on

Those are different layers of the commercial model.

---

6. How to add a new module in the future

A new module should be created only when the feature area is a real product boundary.

6.1 Create a new module when

• the feature can be sold or enabled independently
• the feature has its own permission family
• the feature has its own UI and backend boundary over time
• the feature is meaningful as a product capability
• the feature is not just an enhancement to another module

6.2 Do not create a new module when

• it is only one small screen
• it is only one permission
• it is only a billing variation
• it is only an add-on of an existing module
• it exists only because a team wants a separate code folder

6.3 Future module checklist

Before adding a module, define:

• module key
• business definition
• standalone or package-only status
• permission namespace
• package compatibility
• add-on compatibility
• likely scope restrictions

---

7. Module relationship to packages and add-ons

7.1 Packages include modules

A package may include one or more modules.

7.2 Add-ons may enable modules or sub-capabilities

An add-on may:

• unlock a full module
• or unlock a specialized capability within a package/module ecosystem

7.3 User access still depends on Auth governance

Even if a module is enabled commercially, a user still needs:

• membership module access
• permission grants
• any applicable business-unit scope
• any applicable delegation restrictions for management actions

---

8. Module relationship to permissions

Modules should be the root namespace for permissions.

That means:

• package names must not appear in permission names
• add-on names should appear in permissions only when they represent a distinct capability slice
• module names should remain stable so permission names remain stable

Good examples:

• finance.bills.read
• market.contracts.read
• basic.events.update

Bad examples:

• basic-package-editor
• premium-access-user
• addon-venue-reader

---

9. Summary

Modules are the product capability boundaries of the platform.

They must remain:

• stable
• permission-oriented
• commercially meaningful
• reusable across packages and add-ons

The module catalog is the backbone that connects:

• package design
• add-on design
• permission namespaces
• future backend separation