Skip to content
Kisum • Documentation

Kisum Platform Documentation

Modular, entitlement-driven, access-controlled system 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.
  • Base — Shared business entities and integration points used across modules.
  • Modules — Domain backends (e.g. Finance, Market, Touring, Venue, AI) that implement product logic under the same access and error contracts.
  • 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”

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) — Generated reference for the admin API surface (when published in this docs build).
  • Base — Base service and shared domain layer.
  • Modules — Module layer overview.

Cross-cutting rules

Section titled “Cross-cutting rules”