Live guidance and autopilot MVP

The product principle is continuous guidance with optional execution authority. A manual choice is new context, not an error: cancel automation, preserve what is playing, and recalculate. Mode changes retain the current session and its history.

See DJ GPS acceptance and remaining work for the full manual/auto/hybrid target, and training and feedback for the new offline regression foundation. Live event logging is not yet automatic model improvement.

See Reusable live recipes and Kimi guidance for the subsequent parameterized-recipe and bounded live-model update. The following first-slice results remain the initial execution baseline.

First operational slice

Live clubs now provides a pool picker, Start autopilot, energy target, Skip next, Take control and Stop playback. Pool selection initially shows up to 100 matching tracks from the owner's library; filter BPM and deselect unsuitable recordings. The UI offers 30- or 60-minute sessions and up to three minutes per track. The controller stops when time expires or the pool is exhausted; it does not repeat tracks to fill the requested duration. Browser audio still requires Listen to master. Closing the browser stops monitoring, not the server-side session.

The Rust supervisor in booth-api observes the actual distributed mixer and players, chooses and preloads the next track, and alternates decks 1 → 3 → 2 → 4. Since 2026-09-14 turns also alternate between independent AI DJs: a stored roster of one to four personalities, each with a name, a musical brief, an energy target and a preferred transition length, edited on the AI DJs page between sessions. The acting DJ decides — ranking aims at its energy target and the model prompt carries its brief, its partner's brief as context, and its own private notes; a DJ never reads its partner's. Guidance, co-pilot and autopilot use the same session context. The maximum seconds per track is a ceiling: the planner offers excerpts between about 45% of it and the cap, each ending on a structural boundary, and the same model call that picks the next track picks which excerpt option to play. An optional vocal guard requires both decks to look instrumental across the overlap rather than merely free of a clash; vocal detection is an uncalibrated model score, so this lowers risk and proves nothing. Co-pilot can execute one recommended transition, then relinquishes authority. Manual commands switch to guidance before executing, and the observer responds to a newly selected playing track within the configured pool.

Honest transition capability

Updated 2026-09-14. Autopilot now begins each overlap at a mix point chosen from the incoming and outgoing arrangements — a phrase-aligned exit in the outgoing recording, a structural entry in the incoming one, and a technique matched to that section pair — rather than after a fixed dwell. The operator's per-track time remains a ceiling, and sequential_fade_v1 remains the fallback whenever no usable mix point, tempo or evidence exists. The status payload carries the chosen mix_point. Section, phrase and vocal labels underneath are still unverified model estimates, and no audible acceptance of these transitions has been performed.

The fallback recipe is sequential_fade_v1: four seconds fading the current channel to silence, followed by four seconds fading the next channel in. The incoming track starts only after the outgoing channel is silent and paused; all other channel faders must also be zero. Playback uses original tempo. This is a conservative fallback, not a phrase-aligned, beatmatched blend, echo-out, bass swap or professionally validated transition.

Fades execute per sample in the Rust mixer, not by streaming fader commands from an LLM or browser. Manual channel-fader changes cancel that channel's envelope; Take control cancels all envelopes. Already accepted engine work is drained before a manual replacement is allowed. A pending decode/network operation can delay acknowledgement (bounded by request timeouts); the UI must wait for it.

The supervisor checks the sample clock, expected controls and prepared engine track identity before handing over. An external control change, replaced track, unexpected audible channel, engine failure or journal failure relinquishes automation. Recovery requires an explicit user action; it never silently resumes an autonomous set after process restart. Take control preserves current audio; Stop playback pauses the decks. The normal master output remains 0.70 at startup. Per-track trim only attenuates, using available loudness/peak measurements.

Selection and evidence

Candidates are restricted to the requested workspace-owned pool, excluding played and explicitly skipped tracks. Ranking uses estimated tempo distance, energy target and matching estimated key. When available, the existing Qdrant retriever contributes a small similarity term after Mongo freshness validation. Missing vector evidence falls back to metric ranking. Scores are ranking costs, not percentages or calibrated probabilities. The initial controller used no live model. The subsequent adviser update adds bounded Kimi strategy calls per established track plus explicit requests; models remain outside the audio timing loop.

Planning context includes incoming and outgoing dj-region-evidence-1 summaries where current analysis exists. Good level stability, a small neural timing-fit residual or a high classifier score does not approve beatmatched overlap. Raw analysis and approval identities remain unchanged by autopilot.

Authority, persistence and deployment

Only the booth owner may start full-booth automation, change modes/energy or request a one-shot transition. An assigned human DJ can take control. Listeners can observe but cannot execute. Server routes enforce these permissions on every request. The supervisor uses the booth owner's library; guest-library loading continues through the existing ownership-checked manual path.

MongoDB stores immutable live_dj_events (with the existing tenant prefix for private workspaces): session start and pool, ranked recommendations, skips, observed human choices, requested/acknowledged controls, loads, transitions, interruptions and completion. These are future evaluation/training examples; there is no automatic preference learning in this version. UI history is bounded to recent events; persisted events remain available for subsequent evaluation.

Runtime configuration is server-owned:

• BOOTH_LIVE_MIXER_URL: internal shared mixer endpoint.
• BOOTH_LIVE_PLAYER_URLS: four internal player endpoints, in channel order.
• BOOTH_LIVE_MEDIA_PREFIX: media path prefix relative to player media roots.

The authenticated API is GET/POST /api/v1/live-dj. The UI uses the scoped /api/live-clubs/{club}/autopilot route. Arbitrary engine URLs, media paths and cross-user library IDs are not accepted by Start. The Kubernetes API runs one supervisor replica per workspace; scaling it requires an explicit distributed execution lease. New private-runtime templates include the configuration; existing private pods require an intentional rollout to adopt a changed template. The Festival booth is the first live acceptance deployment.

Acceptance and remaining milestones

Automated tests cover sample-clock fades and cancellation, ranking/history/skip behavior, ten simulated handoffs with no overlapping audible channel, rejection of changed prepared IDs, takeover history, and owner/DJ/listener authority. These establish software behavior, not musical quality or a 30-minute listening acceptance test. Deployment-specific live results are recorded in GitOps.

The next milestone is unchanged and now overdue: a reviewed two-track smooth blend with current approved grid identities, mapped regions, phrase/vocal checks, deterministic scheduling and an auditioned render. Structural overlaps joined autopilot on 2026-09-14 ahead of that review, on unverified estimates; listening acceptance is what would discharge the caveat, and it has not happened. Then validate an uninterrupted 30-minute set, add another recipe, independent DJ personalities and explicit human feedback. FX, samples, calibrated quality scores, adaptive learning and two-track lookahead remain later work. A simulated handoff test must not be reported as a clean professional DJ set.

First live acceptance (2026-09-13)

The Festival booth completed an accelerated four-track run using Levels, Titanium, One Kiss and This Is What You Came For, across decks 1 → 3 → 2 → 4. Monitoring found no simultaneous audible channels. The stereo master stream contained non-zero PCM and peaked at approximately 0.39 full scale. MongoDB contained matching requested/acknowledged controls, all four loads, recommendations and completion. A separate test verified a manual fader was not overwritten, a manually loaded alternative became the recommendation, co-pilot completed exactly one transition, and takeover retained history. Test sessions were stopped afterward.

The test uses 20-second track segments. It validates the live control and audio path, not a full-length DJ set or the subjective musical quality of a blend. The initial empty-deck transport rejection was fixed and the run repeated successfully. Detailed results are stored in GitOps validation.

Seam flourishes are best effort (2026-09-21)

An 8-hour set with a 100-track pool ended after 13 handovers on 2026-09-20 at 23:09 CEST. The journal (live_dj_events) shows the sequence: the outgoing track had run to its end and stopped on its own, no beatmatched overlap fitted the next pair, the cut rotation chose a spinback, the player refused motion on a stopped deck ("Deck motion needs a playing deck"), the mixer forwarded that as HTTP 502, and the supervisor treated the refused flourish as fatal — before the incoming had been started. Silence, and a set marked interrupted.

Two changes. A spinback or brake is only asked of a deck that is still playing; an ended deck gets the plain cut. And every decorative command — the cut gestures (motion, impact) and the overlap script's operators (Beat FX, Sound Color, one-shots, deck motion, slip rolls) — is now sent best-effort: a refusal is journaled as control_rejected with the engine's own reason and the handover continues. Connection failures and takeovers still stop the set. The rejection message now carries the engine's text, so the Live club page says Deck motion needs a playing deck rather than HTTP 502 Bad Gateway.