Strategy

Kithara Strategy

North Star

Build a composable real-time music engine that can power a complete professional DJ workflow without constraining the Core to one product shape.

Professional DJ products define the functional floor for the DJ Engine, not an architectural ceiling. Superpowered is an engineering benchmark for mobile embedding, real-time behavior, and performance, but it does not define Kithara's architectural boundaries.

Product Layers

Universal Core

Core owns protocol-neutral streaming, storage, decoding, audio processing, musical time, scheduling, synchronization primitives, routing, lifecycle, and observability. Its public contracts remain useful outside DJ software.

DJ Engine

The DJ layer composes Core capabilities into track preparation, synchronization, transition planning, mixing, performance controls, routing, effects, recording, and external-control workflows. DJ concepts extend Core; they do not leak into unrelated subsystems.

Kithara App and kithara-ui

Kithara App is the reference product and integration test bed. It must consume the same public engine surfaces available to external applications. kithara-ui provides the shared UI and scene foundation without owning playback or musical state.

Current Product Milestone

The first vertical product milestone is streaming-first mobile mixing on iOS and Android. A Spotify-style transition experience is the initial product reference: automatically create a useful transition, expose it for editing, and execute it reliably.

Mobile is deliberately the first foundation because it imposes stricter lifecycle, network, resource, latency, thermal, and packaging constraints than desktop. An engine designed and accepted under those constraints can support a larger desktop application through the same public contracts. Building the foundation around desktop first would risk assumptions that are expensive to remove when mobile embedding becomes mandatory.

The milestone requires Kithara to:

1. Begin playback after the first playable media data arrives rather than after complete download.
2. Import externally supplied BPM, beat, downbeat, loudness, and optional musical metadata through a typed contract.
3. Generate a canonical editable transition plan for a host-selected track pair.
4. Execute tempo, phase, gain, EQ, filter, and handover automation deterministically.
5. Hold exact beat and downbeat alignment throughout the overlap without accumulated drift.
6. Prove the same behavior through the public Swift and Kotlin SDKs on physical devices.

The first measured resource profile will guarantee two simultaneous tracks. The domain model itself must not encode a fixed deck count: one, two, four, sixteen, or more entities use the same contracts, while measured profiles determine which loads a device can admit safely.

Responsibility Boundaries

• The integrating product owns recommendation, track selection, and ordering and supplies musical-analysis artifacts.
• The DJ Engine owns the versioned transition-plan schema, automatic initial plan, validation, persistence, and compilation.
• Session owns the runtime host grid, synchronization groups, membership, revisions, and sample-accurate execution.
• The application owns artistic decisions such as editing anchors, overlap, automation, and host-tempo changes.
• Core executes accepted commands and never silently replaces an invalid musical transition with an unrelated fallback.

Strategic Principles

1. Streaming first. Playback and transition preparation are bounded by decode readiness, not full media download.
2. Correctness is binary at the musical boundary. A transition with beat, downbeat, or phase drift is not an acceptable reduced-quality result.
3. Plans are editable and reproducible. Automatic decisions produce a canonical plan that can be inspected, changed, persisted, and replayed.
4. One owner per state. UI, SDKs, Queue, and Core do not maintain competing musical timelines.
5. Scale is modeled, limits are measured. Architecture avoids fixed slots; resource profiles define admitted workloads.
6. Platform parity is behavioral. Rust, Swift, Kotlin, and browser surfaces preserve the same semantics even when their backends differ.
7. Real-time paths are bounded. Allocation, blocking, latency, memory, battery, and thermal behavior are measured and enforced.
8. Extensibility is proven by real consumers. Generalization follows a working product need rather than speculative abstraction.

Long-Term Outcome

Kithara should provide the capability families required for a Traktor-class DJ product: preparation, flexible decks and sources, exact synchronization, mixing and routing, effects, cues and loops, scratching and external control, stems and sample workflows, recording, broadcast, and resilient session lifecycle.

Those capabilities are implemented through a more general entity, graph, timeline, and extension model so the same engine can support other interactive music software.

Non-Goals

• Recommendation and ranking logic inside the engine.
• Product-specific UI state inside Universal Core.
• A full DAW or general-purpose sequencer as part of the DJ roadmap.
• Fixed deck counts as a public architectural contract.
• Silent fallbacks that hide invalid analysis, readiness, or synchronization.
• Tactical plans, pull-request lists, release dates, or defect journals in the strategic Wiki.