Artist Product Vision
Related documentation: Artist Module Backend · Artist Endpoint Map · Frontend Artist · Artist Module Backend API
Purpose
Section titled “Purpose”This page explains what the artist base module is supposed to be in product terms.
It should be read as the product definition behind the current runtime.
Short definition
Section titled “Short definition”The Artist module is Kisum’s artist/agency network, booking, contract, touring, and relationship system.
It is the part of Kisum where artists, agencies, promoters, buyers, and artist-side operational crew interact around real commercial workflows.
Core product idea
Section titled “Core product idea”The Artist module should answer questions like:
- who represents this artist
- which agency owns this roster
- when is this artist available
- what requests, offers, holds, and bookings are active
- which contract is in progress
- which signer is blocking the deal
- what travel / hotel / hospitality / technical proposal still needs approval
- which promoter has booked this artist before
- how trustworthy is this counterparty
- what booking-related finance state is visible right now
Product scope
Section titled “Product scope”The module combines several concerns into one operational surface:
Directory
Section titled “Directory”- artists
- agencies / market companies
- people
- taxonomy
- geo
Representation
Section titled “Representation”- company claims
- roster ownership
- artist representation claims
- disputes
Discovery
Section titled “Discovery”- availability
- availability-based search
- marketplace research
Booking
Section titled “Booking”- requests
- offers
- counters
- holds
- confirmed bookings
- booking activity
Contracts
Section titled “Contracts”- template libraries
- booking-linked contracts
- versions
- signers
- signatures
- attachments
- event timeline
Touring and logistics
Section titled “Touring and logistics”- tours
- stops
- routing
- itinerary
- booking logistics
- promoter-submitted proposals
- one-layer approvals
Relationship intelligence
Section titled “Relationship intelligence”- relationship summaries
- private notes
- flags
- ratings
- trust score
- booking history
Read models
Section titled “Read models”- agency dashboards
- promoter dashboards
- shortlists
- marketplace reads
- booking finance visibility
What the module is not
Section titled “What the module is not”The Artist module is not:
- Auth
- Core
- Finance truth
- Venue operations
- ticketing source of truth
- full production ERP
It is the artist/agency commercial workflow layer.
Product UX implication
Section titled “Product UX implication”Frontend should present the Artist module as one connected system.
The user should not feel they are jumping between unrelated sub-products.
Recommended product sections are:
- profiles
- representation
- avails
- bookings
- contracts
- tours
- logistics approvals
- relationship intelligence
- dashboards
- shortlists
- finance visibility
- marketplace
Runtime implication
Section titled “Runtime implication”Because the runtime is already broad, the documentation should no longer speak about the current system as “phase 1 / phase 2 / phase 3 / phase 4” for frontend understanding.
For documentation and frontend integration, this is now one system with multiple capability areas.
Summary
Section titled “Summary”The Artist module is where Kisum becomes the operating network for artist-side live-entertainment business.
It should be understood as:
- artist and agency CRM
- booking workflow
- contract workflow
- touring coordination
- logistics approval workflow
- relationship memory and trust
- marketplace and dashboard read models