Reusable live recipes and Kimi guidance

The live engine executes stored recipe parameters deterministically. An LLM is not called for each fader movement or for each execution of a recipe. Music selection, instructional advice and execution authority are separate concerns.

Implemented in this iteration

• MongoDB live_transition_recipes stores immutable parameterized versions.
• Live clubs lets the owner browse saved versions, select one or save changed fade durations as a new version. Changing a recipe requires taking control.
• The selected version remains active across guidance/co-pilot/autopilot changes and a newly started set. Restarting the process defaults to v1; stored versions remain selectable. The current selection is not a crash-resume mechanism.
• Session-start and transition-start events retain the recipe snapshot. Recipe IDs identify a family/version; parameters determine the actual execution.
• Kimi K3 reviews a shortlist asynchronously, outside the mixer/control loop.
• Guidance shows preparation steps for the chosen track, candidate cue timing, estimated tempo adjustment and vocal/harmonic/timing uncertainties.

The only supported live family is currently sequential_fade: fade out, confirm silence, pause the outgoing deck, start the next deck at original tempo, then fade in. Durations are independently configurable from 1–12 seconds. The original default is 4 seconds out / 4 seconds in. This remains a non-overlapping fallback, not a phrase-aligned blend. Unsupported families and parameters are rejected rather than silently approximated.

The offline B2B lab has a separate beat-based recipe schema, EQ/bass-swap rendering and human-rated attempts. Those recipes are not yet executed by the distributed live players. New live versions are not automatically better; they need audition and comparison. Live rating and automated parameter optimization remain work.

Moderate model policy

Kimi receives one automatic strategy request per established current track, including an initial shortlist consultation. A different human-selected next track triggers replanning; changing modes requests a fresh assessment. Repeated searches and playhead updates do not create new strategy identities. Requests deferred by the cooldown are reconsidered while the context remains eligible. The owner may also explicitly press Ask DJ adviser. Hard limits are 12 requests per session, at least 30 seconds between requests, one in-flight request, five candidates, a 24 KB context limit and a 15-second deadline. Failed/cancelled requests still consume the request budget. Starting another session resets the per-session counter; there is not yet a cluster-wide monetary budget.

Search, analysis, state polling, envelope scheduling and repeated execution make zero model calls. Kimi receives metadata and bounded musical evidence, not audio or a whole-library embedding dump. Existing Rig K3 output-token limits apply; request counts are not a monetary cost estimate.

An explicit human-selected next track cannot be replaced by the model. Responses must select a supplied track and the selected recipe ID, with bounded text. A superseded choice, takeover, recipe change, active fade or late result cannot replace the current plan. Cancelled work is aborted; failure preserves local ranking. Provider error bodies and credentials are not shown in the journal.

Model explanations remain unverified advice. They cannot authorize overlap, change a recipe, invent reviewed cue points or send commands. A model-selected alternative gets its own analysis evidence; the old track's evidence is not reused for the new one.

API and deployment

• GET /api/v1/live-dj: state, selected recipe, guidance, and adviser budget/status.
• GET /api/v1/live-dj/recipes: saved versions (bounded to 100).
• POST /api/v1/live-dj with action: recipe and the complete validated recipe: persist/select a version while automation is inactive.
• POST /api/v1/live-dj with action: refresh_advice: explicitly request advice, subject to the budget/cooldown. UI routes enforce booth ownership.

Example recipe:

{
  "id": "sequential_fade",
  "version": 2,
  "name": "Long exit, shorter entrance",
  "family": "sequential_fade",
  "fade_out_seconds": 6.0,
  "fade_in_seconds": 2.5
}

GitOps configures AI_BACKEND=moonshot, AI_MODEL=kimi-k3 and the server-owned provider endpoint. AI_API_KEY references Kubernetes Secret aidj-live-model; no credential is committed. tools/configure-live-model.py CREDENTIAL_FILE provisions it from a local assignment file. The new-private-runtime template uses the same provider configuration; existing private runtime pods need a rollout. Provider settings do not go to the browser.

Still needed for the professional DJ MVP

The distributed engine explicitly lacks phase synchronization and master-tempo key lock. It must gain a tested synchronization path before automatic phrase-aligned blends can be claimed. Numerical beat-fit residuals are not musical timing approval. Validated region/phrase/vocal evidence is still required for a chosen overlap.

Raveform metadata has now been imported into research collections, with a train-only timing baseline. It is not yet used by the live planner; see human DJ corpus. No trained DJ-quality model is deployed. Programmed templates, an LLM's general advice, synthetic ground truth and professional listener labels are different kinds of knowledge. The offline training foundation does not change that status. See training and feedback and MVP acceptance.

Strategy loop and acceptance boundary

The strategy identity consists of the current track, explicit human next-track choice and saved recipe version. It excludes the playhead and local ranking order. A submitted request consumes that identity even if it fails: the engine continues locally instead of retrying the provider indefinitely. Takeover cancels outstanding advice; switching modes requests reassessment without resetting history or the session budget. Fast test sets may advance during the cooldown and intentionally receive fewer model calls.

The present typed response selects a shortlisted track and the already selected recipe, with an explanation and handoff note. It cannot yet choose among live smooth-blend/drop/EQ/FX templates, schedule an approved bar, or continue a partially completed two-channel human overlap. Autopilot currently requires the other channels to be silent. Those are remaining MVP capabilities, not benefits that a larger model context or strict JSON alone provides. Asynchronous REVIEW and learned critic promotion are separate future integrations.

Live validation on 2026-09-13 accepted a Kimi K3 response for the four-track benchmark pool, preserved the supplied recipe ID and retained unknown timing/ vocal evidence. Saving recipe v2 succeeded; changing its parameters without changing its version was rejected. The test ran in guidance mode with no audio commands. This validates API integration, not the musical quality of a set.

A subsequent manual-choice notification for Titanium triggered the second bounded request; Kimi preserved Titanium and the same recipe, with zero device control events. This was an API guidance test, not an audible transition or a physical DJ performance.