Kisum Platform Documentation
Introduction
Section titled “Introduction”Welcome. This site describes Kisum as a platform: how pieces fit together, where responsibilities live, and what rules stay consistent as products and teams grow. It is written for engineers and operators who implement or extend the system—not as marketing copy, but as a shared map you can trust when you debug production, design a feature, or onboard a new service.
Kisum is built as a multi-tenant, modular product. Companies subscribe to packages and add-ons; users belong to companies and receive memberships, roles, and fine-grained permissions. Nothing in the UI is authoritative for access—Auth and Core resolve what is allowed; module backends enforce it; the frontend reflects reality and never becomes the source of truth. If that separation ever blurs, this documentation calls it out.
Use the sections below to move from the big picture to concrete specs: system narrative, architecture diagrams, backend domains (including OpenAPI-backed API references where published), cross-cutting access and middleware, and operational notes. When in doubt, start with System Home for the full platform narrative, then drill into the area you are changing.
What this site contains
Section titled “What this site contains”At a glance, the platform is organized like this:
- Auth — Identity, sessions, JWT/JWKS, memberships, roles, permissions, delegation, and effective access (what a user may actually do in a company).
- Core — Commercial model: packages, add-ons, company subscriptions, and entitlements that define what a tenant has purchased.
- Promoters — Main promoter-facing business backend/module surface, historically rooted in the shared Base backend runtime.
- Modules — Base and addon backends (e.g. Promoters, Artist, Finance, Touring, Venue, AI) that implement product logic under the same access and error contracts.
- AI addon support systems — Documented stacks such as Chat + MCP (Node) and AI Event Intelligence Copilot Prototype extend AI-assisted workflows; they are not Auth/Core sources of truth.
- Frontend — Presents the right UX from resolved access; does not own authorization decisions.
- Cross-cutting — Access control integration, middleware, caching, admin platform behavior, migration, QA scenarios, and shared error contracts—documented so behavior stays consistent across services.
This is not a single monolith with one permission table. It is a layered architecture: clear boundaries, independent deployables where possible, and explicit rules for how access flows from company ownership to a single request.
Start here
Section titled “Start here”- System Home — Full “what this system is” narrative, diagrams, and core ideas (entitlements vs membership, effective access, delegation).
- Architecture Overview — Platform-wide architecture and integration points.
- Architecture Diagrams — Visual maps and flows.
- Backend Overview — How backends are structured and how they relate to Auth and Core.
- Frontend Overview — Client responsibilities and constraints.
- Infra Tasks — Infrastructure and rollout-related notes.
Backend domains
Section titled “Backend domains”- Auth — Auth service behavior and contracts (see also Auth API under Backend → Auth in the sidebar for OpenAPI).
- Core — Core platform and commercial model.
- Admin API (OpenAPI) — Published reference for the current admin API surface.
- Promoters Module — Promoter-facing business backend/module surface.
- Modules — Module layer overview, rules, and published module pages.
- Finance Module — Current Finance backend implementation, route families, and migration status.
- Finance API — Finance route families, entitlement rules, and current API behavior summary.
- Artist Module — Current artist/agency booking-network backend implementation, currently shipped from
Backend-Kisum-Artists. - Artist API — Artist route families, dual-auth contract, include/subresource read model, and current API behavior summary.
- Chat + MCP (Node) — AI-addon support stack: AI agent + MCP microservices; separate from Backend-MCP-Kisum (Go).
- Venue Module — Target Venue backend contract for venue management, contracts, availability, and finance-linked operations.
- Venue API — Planned Venue route families and integration boundary.
- AI Event Intelligence Copilot Prototype — Standalone Node/Express promoter copilot prototype with Mongo-backed sessions, venue/agency lookup, and simulation flows; currently documented under the AI addon support layer.