Skip to content
Kisum • Documentation

Venue Module Backend API

Related documentation: Venue Module Backend · Backend Modules · Frontend Venues · Error Contract

Status

Section titled “Status”

This page documents the practical route contract for Backend-Kisum-Venues.

  • It is not yet a generated OpenAPI export.
  • Some routes are live and repository-backed now.
  • Some routes are still registered but placeholder-only or generic stub responses.
  • Import flows are command/migration based and are not browser API routes.
  • This page is the source-of-truth endpoint map for both current and pending Venue routes.

Auth modes

Section titled “Auth modes”

Tenant-scoped user routes

Section titled “Tenant-scoped user routes”

Require:

  1. Authorization: Bearer <JWT>
  2. x-org: <company_id>

Internal machine routes

Section titled “Internal machine routes”

May require:

  1. X-Internal-API-Key: <VENUE_INTERNAL_API_KEY>

Required direction

Section titled “Required direction”

Every tenant route should fail closed with:

  • JWT validation
  • tenant context enforcement
  • module gate for venue
  • permission-aware route handling

Runtime route groups

Section titled “Runtime route groups”

Health

Section titled “Health”
  • GET /health

Purpose:

  • infrastructure health probe for deployment/runtime checks

Role in the system:

  • tells load balancers, containers, and operators that the Venue service process is alive
  • does not carry venue business meaning

Current implemented endpoints

Section titled “Current implemented endpoints”

These routes are backed by current handlers and repositories in the live runtime.

Internal Base-facing venue reads

Section titled “Internal Base-facing venue reads”

  • GET /internal/venues

    • Status: live
    • Primary caller: trusted internal services such as Backend-Kisum
    • Purpose: list Venue-owned venue records without direct Postgres coupling
    • System role: gives other Kisum backends read-only access to venue inventory that Venue owns

  • GET /internal/venues/{id}

    • Status: live
    • Primary caller: trusted internal services
    • Purpose: fetch one Venue-owned venue record by Kisum internal venue id
    • System role: supports service-to-service reads where another backend needs authoritative venue detail

  • GET /internal/venues/{id}/inquiry

    • Status: live
    • Primary caller: trusted internal services
    • Purpose: fetch venue inquiry-oriented detail from the Venue service instead of duplicating venue lookup logic elsewhere
    • System role: keeps inquiry/detail consumption inside the Venue boundary rather than copying venue state into Base/Admin databases

Internal Admin-facing venue routes

Section titled “Internal Admin-facing venue routes”

  • GET /internal/admin/venues

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: list normal managed venue records for Admin control-plane screens
    • System role: gives Admin a Venue-owned runtime source of truth for venue management without direct DB reads

  • GET /internal/admin/venues/sleeping

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: list imported sleeping venues that are still under Kisum holding ownership
    • System role: separates takeover inventory from active tenant-managed venue inventory

  • GET /internal/admin/venues/{venueId}

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: fetch one venue by numeric imported venue_id
    • System role: preserves Admin’s stable numeric venue identity for legacy/sleeping venue workflows

  • POST /internal/admin/venues

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: create a new venue record through Venue service APIs
    • System role: keeps venue creation inside the Venue domain instead of Admin writing Venue tables directly

  • PATCH /internal/admin/venues/{venueId}

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: update one venue through the numeric imported venue_id
    • System role: supports Admin editing against Venue truth while preserving the numeric-id operational contract

  • DELETE /internal/admin/venues/{venueId}

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: delete/deactivate a venue through Venue-owned persistence rules
    • System role: keeps destructive venue-state changes inside the Venue backend boundary

  • GET /internal/admin/venue-types

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: list the imported venue_type catalog
    • System role: lets Admin use the same Venue-owned venue-type lookup that the import/runtime uses

  • POST /internal/admin/venues/{venueId}/takeover-approvals

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: create a takeover approval request for a sleeping venue
    • System role: keeps sleeping-venue claim workflow state inside Venue, not inside Admin

  • GET /internal/admin/venues/{venueId}/takeover-approvals

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: list takeover approval records for one sleeping venue
    • System role: lets Admin inspect approval state from Venue truth instead of reconstructing workflow state elsewhere

  • GET /internal/admin/venues/{venueId}/takeover-audit

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: list takeover audit entries for one venue
    • System role: keeps workflow auditability inside Venue so Admin can render the lifecycle without direct database reads

  • GET /internal/admin/venues/{venueId}/reconciliation

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: fetch the latest post-activation reconciliation summary for imported venue artifacts
    • System role: makes imported-record carry-over visible after sleeping-venue activation and closes the import-to-runtime handoff

  • POST /internal/admin/venues/{venueId}/activate

    • Status: live
    • Primary caller: Backend-Kisum-Admin
    • Purpose: activate a sleeping venue into active ownership/runtime state after approval
    • System role: closes the import-to-takeover lifecycle inside the Venue module by transferring ownership and persisting audit/reconciliation state

Boundary rules:

  • these are internal service routes, not browser routes
  • Backend-Kisum-Admin is the browser-facing BFF
  • Venue remains the runtime source of truth
  • numeric venue_id is the Admin-facing stable venue identity for these flows

Venues

Section titled “Venues”

  • GET /api/v1/venues

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: list the current tenant company’s venue records
    • System role: drives the venue app shell and tenant-scoped venue discovery
    • Current contract: supports page, limit, q, status, and city

  • POST /api/v1/venues

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: create a venue record for the current tenant
    • System role: establishes the operational venue entity the tenant will manage
    • Current contract: accepts operating metadata through operatingHours, restrictions, and technicalSpecs

  • GET /api/v1/venues/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: fetch one venue by Kisum internal id
    • System role: supports venue detail screens and downstream venue-scoped workflows

  • PATCH /api/v1/venues/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: update venue master data
    • System role: lets Venue own venue profile/operational master data instead of Base/Admin or frontend-local state
    • Current contract: updates the same operating metadata fields exposed on create

  • DELETE /api/v1/venues/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: soft-delete a venue record
    • System role: keeps venue archival/deletion semantics inside the Venue backend

Boundary rules:

  • v1 product contract is effectively 1 company = 1 venue
  • route design should still leave room for future multi-venue support

Spaces

Section titled “Spaces”

  • GET /api/v1/spaces

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: list spaces for the current tenant, optionally filtered by venue
    • System role: spaces are the operational scope unit used by bookings, assignments, and calendar views
    • Current contract: supports page, limit, q, status, and venueId

  • POST /api/v1/spaces

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: create a new space within a venue
    • System role: models the actual rentable/operational subunits of a venue

  • GET /api/v1/spaces/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: fetch one space by Kisum internal id
    • System role: supports detail/configuration screens for a single space

  • PATCH /api/v1/spaces/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: update a space’s master/operational data
    • System role: keeps the operational scope definition inside Venue truth

  • DELETE /api/v1/spaces/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: remove or archive a space record
    • System role: allows the Venue module to own the lifecycle of rentable spaces

Boundary rules:

  • spaces behave like lightweight BU-style operational scopes
  • frontend filtering and manager visibility are expected to be built around spaces

Availability

Section titled “Availability”

  • GET /api/v1/availability

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: list availability blocks for one or more spaces
    • System role: powers calendar availability views and conflict evaluation inputs

  • POST /api/v1/availability/blocks

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: create an availability block such as a hold, maintenance window, or manual block
    • System role: lets Venue operators reserve or restrict space usage before a booking exists
    • Current contract: expiresAt is supported for hold blocks; maintenance and blackout are valid block statuses

  • PATCH /api/v1/availability/blocks/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: update an existing availability block
    • System role: lets operators correct or move blocks without delete-and-recreate churn

  • DELETE /api/v1/availability/blocks/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: delete an availability block
    • System role: reopens the blocked timeslot for future booking/availability use

Boundary rules:

  • same-space conflicts should be prevented
  • simultaneous bookings across different spaces are valid
  • holds, maintenance, blackout, and manual block semantics belong here
  • expired hold blocks no longer participate in conflict checks

Bookings

Section titled “Bookings”

  • GET /api/v1/bookings

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: list bookings for the tenant venue/spaces
    • System role: provides the core commercial-operational booking workload for the venue app

  • POST /api/v1/bookings

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: create a booking tied to one or more spaces and a Market counterparty reference
    • System role: establishes the primary venue commercial/operational record before contracts, deposits, and event operations
    • Current contract: accepts either marketCompanyId, marketPersonId, or both; optionally carries eventId (existing venue event row to link) and/or promoterEventId (canonical promoter event ref) so the booking arrives already wired to its event

  • GET /api/v1/bookings/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: fetch one booking by Kisum internal id
    • System role: supports booking detail, follow-up workflow, and downstream contract/finance/ops screens

  • PATCH /api/v1/bookings/{id}

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: update booking status
    • System role: controls confirmation-sensitive transitions, including the handoff point into Finance workflow when a booking becomes confirmed
    • Current contract: on confirm, SyncBookingEvent resolves the linked venue_events row in this order — eventId (explicit link) → promoterEventId (upsert on (company_id, promoter_event_id)) → placeholder shadow keyed on booking_id. The resolved event id is then back-linked onto the booking row so subsequent reads expose eventId without re-syncing.

Boundary rules:

  • bookings may include multiple spaces
  • included spaces define operational visibility
  • transition to confirmed is a Finance-handoff boundary
  • Venue orchestrates the booking state; Finance owns the resulting finance truth
  • the booking ↔ event link uses canonical promoter event identity whenever available; placeholder events are last-resort fallbacks for off-platform promoters

Customers / overlays

Section titled “Customers / overlays”

  • GET /api/v1/customers/search

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: search canonical counterparties for booking/customer selection
    • System role: lets the venue app look up shared-party records without making Venue a second master-data system
    • Current contract: merges Market company/person search results with tenant-local overlay matches

  • POST /api/v1/customers/{id}/overlays

    • Status: live
    • Primary caller: Frontend-Kisum-Venues
    • Purpose: create venue-specific overlay data for a selected shared party
    • System role: stores local notes, risk, preferences, and operational context while Market stays canonical
    • Current contract: supports overlay creation for either company-level or person-level Market references

Boundary rules:

  • Artists owns canonical party identity
  • Venue stores venue-specific overlays only

Mixed live and pending target endpoints

Section titled “Mixed live and pending target endpoints”

These routes matter to the module contract. Events, deals, contracts, deposits, and operations (incl. templates) are now live and repository-backed. Reports remain generic stubs pending Phase 7.

Events

Section titled “Events”

Ownership boundary (read this first). Canonical event truth lives in the Promoter module, not in Venue. A venue_events row is either:

  • a reference to a real promoter-owned event (promoterEventId set, isPlaceholder = false), OR
  • a placeholder for an off-platform promoter (isPlaceholder = true, promoterEventId nil) that can later be reconciled to a real promoter event via POST /api/v1/events/{id}/link-promoter, mirroring the sleeping-venue takeover pattern.

Venue stores venue-side operational state on top of that reference (title, description, eventType, status, start/end, spaceIds, payload, plus placeholder promoter context when applicable). Venue never invents promoter master data.

  • GET /api/v1/events

    • Status: live
    • Intended purpose: list venue event references in this company
    • System role: surfaces the operational event roster — booking-confirm sync, placeholder reconciliation, and explicit POST are the three creation paths that populate it
    • Filters: status, venueId, bookingId, promoterEventId, placeholder (only | exclude), fromAt, toAt, page, limit

  • POST /api/v1/events

    • Status: live (strict validation)
    • Intended purpose: create a venue-side event reference
    • System role: lets a tenant attach a venue event for either a real promoter event or an off-platform promoter without granting Venue authorship of event identity
    • Required body shape: must carry exactly one of
      • promoterEventId: the canonical promoter event id (real on-platform promoter), OR
      • placeholder = true plus placeholderPromoterName (and optionally placeholderPromoterEmail, placeholderNotes) for an off-platform promoter
    • Rejects both-set, neither-set, and missing-placeholder-name with 400/422

  • GET /api/v1/events/{id}

    • Status: live
    • Intended purpose: fetch one event record with placeholder + promoter linkage
    • System role: feeds operations, deposits, and finance-status views

  • PATCH /api/v1/events/{id}

    • Status: live
    • Intended purpose: update venue-side operational fields on an event record
    • System role: keeps venue-side operational state inside Venue while never silently mutating promoter linkage
    • Allowed mutations: title, description, eventType, status, startAt, endAt, spaceIds, payload, businessUnitId, bookingId. On placeholder rows, also accepts placeholderPromoterName, placeholderPromoterEmail, placeholderNotes.
    • Never mutates promoterEventId or isPlaceholder — promotion happens via link-promoter.

  • POST /api/v1/events/{id}/link-promoter

    • Status: live
    • Intended purpose: promote a placeholder venue event to a canonical promoter-event reference once the previously off-platform promoter joins Kisum
    • System role: the reconciliation hook between the venue-side placeholder and the Promoter module’s canonical event identity
    • Body: { "promoterEventId": "..." }
    • Rejects non-placeholder rows and rejects promoterEventId values already linked to a different venue event in the same company

Pending phase intent:

  • Promoter HTTP client (Venue Phase 3): call GET {PROMOTERS_BASE}/internal/events/:promoterEventId before persisting refs when strict validation is required. Resolver is live on Promoters (2026-05-27): accepts publicEventId UUID or Mongo _id; auth X-Internal-API-Key = Promoters INTERNAL_API_KEY. Today Venue still trusts caller format unless the client is wired.

Deals

Section titled “Deals”

  • GET /api/v1/deals

    • Status: live
    • Intended purpose: list venue-side commercial deal records
    • System role: should become the read-model for venue commercial structures before contract execution

  • POST /api/v1/deals

    • Status: live
    • Intended purpose: create a commercial deal structure
    • System role: captures venue-specific pricing/commercial terms before contract generation

  • GET /api/v1/deals/{id}

    • Status: live
    • Intended purpose: fetch one deal structure
    • System role: supports review and downstream contract generation

  • PATCH /api/v1/deals/{id}

    • Status: live
    • Intended purpose: update a deal structure
    • System role: keeps venue-side commercial negotiation state inside Venue

Pending phase intent:

  • commercial terms persistence
  • booking-to-deal linkage
  • contract-generation input modeling

Contracts

Section titled “Contracts”

  • GET /api/v1/contracts

    • Status: live
    • Intended purpose: list venue contract records
    • System role: becomes the canonical read surface for venue-rental agreement workflow state

  • POST /api/v1/contracts

    • Status: live
    • Intended purpose: create a draft contract record
    • System role: starts Venue-owned contract lifecycle state

  • GET /api/v1/contracts/{id}

    • Status: live
    • Intended purpose: fetch one contract record
    • System role: supports draft review, signer assignment, and signature-status visibility

  • PATCH /api/v1/contracts/{id}

    • Status: live
    • Intended purpose: update draft contract metadata
    • System role: preserves Venue ownership of the rental-contract lifecycle

  • POST /api/v1/contracts/{id}/generate

    • Status: live
    • Intended purpose: generate a contract document from booking/deal/template data
    • System role: bridges structured venue data into a signable agreement artifact

  • POST /api/v1/contracts/{id}/send-for-signature

    • Status: live through local adapter
    • Intended purpose: send a contract to Adobe Sign
    • System role: initiates backend-mediated signature orchestration

  • POST /api/v1/contracts/{id}/resend

    • Status: live through local adapter
    • Intended purpose: resend a contract for signature
    • System role: supports operational recovery in the signature workflow

  • GET /api/v1/contracts/{id}/signature-status

    • Status: live
    • Intended purpose: fetch the signature state of a contract
    • System role: lets Venue surface contract execution progress to the product UI

Boundary rules:

  • Venue owns contract lifecycle state
  • Adobe actions are backend-mediated only
  • frontend must never hold Adobe credentials
  • the current runtime persists signature state locally through an adapter boundary; real Adobe upstream sync is still pending

Deposits / finance visibility

Section titled “Deposits / finance visibility”

  • GET /api/v1/deposits

    • Status: live
    • Intended purpose: list venue deposit workflow records or operational finance visibility rows
    • System role: gives Venue operators a finance-linked operational view without making Venue the finance source of truth

  • POST /api/v1/deposits

    • Status: live
    • Intended purpose: create deposit expectation or workflow metadata
    • System role: tracks venue-side deposit orchestration inputs and creates the linked Finance income invoice through Finance POST /api/income machine source=venue_deposit mode

  • PATCH /api/v1/deposits/{id}

    • Status: live
    • Intended purpose: update deposit workflow metadata
    • System role: lets Venue manage operational deposit progress while syncing the linked Finance income invoice through Finance PATCH /api/income/{id} machine source=venue_deposit mode

  • GET /api/v1/events/{id}/finance-status

    • Status: live
    • Intended purpose: show operational finance status for an event/booking
    • System role: exposes Finance-derived visibility to Venue users while Finance remains the persistence truth

Boundary rules:

  • Venue may expose operational finance/deposit state
  • Finance owns obligations, invoices, payments, settlements, and accounting truth
  • deposit invoice sync is now real through Finance income machine mode, and Venue should prefer Finance status once financeRecordId exists

Operations

Section titled “Operations”

Venue-side operational readiness for events. Checklists may be assigned to an event, a space, and/or a booking, may carry an explicit readinessState (not_started → in_progress → blocked → ready → complete), and may be created blank, from inline tasks, or by cloning a reusable template’s tasks at create time.

  • GET /api/v1/operations/checklists

    • Status: live
    • Intended purpose: list checklist instances
    • System role: becomes the venue-operations execution surface after a booking is accepted
    • Filters: eventId, spaceId, bookingId, status, readiness, page, limit

  • POST /api/v1/operations/checklists

    • Status: live
    • Intended purpose: create a checklist instance
    • System role: starts operational readiness workflows owned by Venue
    • Body: name required; optional eventId / spaceId / bookingId for assignment; optional templateId clones the template’s tasks when no inline tasks array is provided; optional readinessState, dueAt, inline tasks[]

  • GET /api/v1/operations/checklists/{id}

    • Status: live
    • Intended purpose: fetch one checklist with its task list and readiness state
    • System role: feeds the venue-side execution view

  • PATCH /api/v1/operations/checklists/{id}

    • Status: live
    • Intended purpose: update checklist metadata, progress, readiness
    • System role: tracks how prepared the venue is to execute an event
    • Task-list semantics: the task list is replaced only when the body explicitly includes a tasks array; partial metadata updates leave existing tasks untouched

  • GET /api/v1/operations/templates

    • Status: live
    • Intended purpose: list reusable checklist templates for this company
    • System role: lets venues encode standard prep flows once and clone them per event

  • POST /api/v1/operations/templates

    • Status: live
    • Intended purpose: create a checklist template with reusable tasks

  • GET /api/v1/operations/templates/{id}

    • Status: live
    • Intended purpose: fetch one template with its tasks

  • PATCH /api/v1/operations/templates/{id}

    • Status: live
    • Intended purpose: update template metadata and replace the template task list

Reports

Section titled “Reports”

All four reports share the same query contract: fromAt, toAt (RFC3339; default = last 30 days), bucket (day | week | month; default month), plus optional venueId, spaceId, businessUnitId, marketCompanyId, marketPersonId.

Each Finance-derived report carries a financeLinked boolean and, when false, a financeMessage explaining that the totals reflect Venue data only.

  • GET /api/v1/reports/utilization

    • Status: live
    • Intended purpose: report booked + blocked minutes per (bucket, space) so operators can see how much of each space’s time was used vs free
    • System role: pure Venue truth — joins venue_bookings (status in tentative/hold/pending/confirmed) and venue_availability_blocks (excluding expired holds) against venue_spaces for the space name. No Finance call.

  • GET /api/v1/reports/revenue

    • Status: live
    • Intended purpose: merge Venue-side deposit amounts with Finance-derived invoiced + paid totals per bucket
    • System role: gives Venue users a reporting view while Finance remains the settlement/invoice truth. Returns per-bucket rows + totals; financeLinked = false when the Finance HTTP client is not configured, with Venue deposit numbers still populated.

  • GET /api/v1/reports/profitability

    • Status: live (Finance-dependent)
    • Intended purpose: report revenue minus cost per bucket as net = revenue − cost, both pulled from Finance (GET /api/income and GET /api/bills)
    • System role: exposes derived commercial health using Finance-linked data rather than replacing Finance. Returns empty rows with financeLinked = false when Finance is not configured.

  • GET /api/v1/reports/customers

    • Status: live
    • Intended purpose: group bookings by Artists party id (company or person), enriched with the most-recent overlay display name; report booking / confirmed / cancelled counts + last-booking timestamp per customer
    • System role: supports relationship and booking analysis while Market remains the canonical party system. Top-level totals additionally include Finance invoiced + paid (company-wide) when the Finance client is configured.

Implementation notes:

  • Aggregations run as ad-hoc SQL inside internal/venue/repositories/reports_postgres.go; no materialized views (deferred until real load justifies the refresh strategy).
  • Finance enrichment uses FinanceHTTPReportingClient (internal/venue/service/finance_reporting_http.go) which calls GET /api/income and GET /api/bills with the workspace internal Bearer + x-org header (same pattern as the existing deposit-sync client), and applies the fromAt / toAt window client-side because Finance does not expose date-range filters today.
  • The Finance customerId space is not the same as the Artists party id space; per-row Finance enrichment of the customers report is intentionally out of scope. Finance totals appear at the report-total level only.

Data-shape rules

Section titled “Data-shape rules”

Venue type linkage

Section titled “Venue type linkage”

Venue rows should use:

  • venue_type_id

which links to:

  • venue_type(venue_type_id)

type_legacy_id should not remain the long-term name for this column.

Legacy venue compatibility

Section titled “Legacy venue compatibility”

Venue rows should preserve:

  • venue_id
    • numeric imported venue id
  • source_mongo_object_id
    • imported Mongo _id
  • unique_id
    • compatibility field

Geo compatibility

Section titled “Geo compatibility”

Venue rows may retain:

  • raw country
  • raw city
  • raw country_iso2

but should prefer canonical Market ids when available:

  • country_id
  • city_id

Nullable city rule

Section titled “Nullable city rule”

city and city_id may be NULL.

The API and frontend must not assume all venues have a city.

Non-API import contract

Section titled “Non-API import contract”

Legacy import is handled by:

  • SQL migrations
  • cmd/import-sleeping-venues

not by public HTTP routes.

Phase-one import includes:

  • venues_type -> venue_type
  • venues -> venues plus related detail tables

Imported inventory rules:

  • rows land under a Kisum holding company
  • rows are sleeping and claimable
  • takeover is a separate workflow phase