settled-reach/docs/workshops/llm-voice-pipeline/round-3-inputs.md

title, description, type, status, workshop, agent, round, created

title	description	type	status	workshop	agent	round	created
Round 3 Inputs	Binding decisions from Jeroen after rounds 1-2 as inputs for round 3	workshop	archived	llm-voice-pipeline		3	2026-03-07

LLM Voice Pipeline Workshop — Round 3 Inputs

Source: Team lead interview with Jeroen after Rounds 1-2 Date: 2026-03-07

---

Jeroen's Decisions

These are binding inputs for Round 3. The team produces the D-record and implementation plan around these.

1. Scope: Behaviors + Dialogue (full pipeline)

"We don't introduce a precision laser cutting tool and then use it only to open boxes." Both observable behaviors AND dialogue get re-voiced. This is the long-term architecture.

2. Tell Treatment: Passthrough with Context Influence

Tells are mechanical signals, not culture. They stay as base text — always. Swapping them confuses the player.

However, tells INFORM the LLM context for dialogue and behavior. When a player engages an NPC who has an avoidance tell, the NPC's dialogue should be phrased in an avoiding way. The tell itself is untouched; the tell's presence shapes the re-voicing prompt for surrounding content.

This is a critical distinction: tells are read-only inputs to the LLM, never LLM outputs.

3. Spike Strategy: Two Spikes

Spike 1 — Plumbing + Quality (no integration):

• Build the Rust llama-cpp-rs wrapper. Load Gemma 2B and Phi-3. Prove the plumbing works: accept prompt, return text.
• Then Jeroen, Mellanie, and Paula manually craft prompts — culture injectors, behavior seeds, dialogue seeds — and feed them through by hand.
• Test both models against the same prompts. Answer the question: "does this even play?"
• No game integration, no queue, no cache. Just the inference tool and manual prompt experimentation.

Spike 2 — Integration:

• Wire the validated runner into the pre-voicing pipeline.
• Queue, cache-as-determinism, thread pool isolation, baked content generation, fallback behavior.
• The full architecture as designed by the team.
• Uses whichever model won Spike 1.

4. D-123 Amendment

Amend D-123 to cover both baked (build-time, human-reviewed) and pre-voiced (runtime background) modes. Supersede D-124. Paula's distinction between the two modes must be explicit in the amended record.

5. Model Provenance

Strong preference against Chinese-origin models (Qwen/Alibaba). Gemma (Google) is the primary candidate. Phi (Microsoft) is the fallback. Reconsider the constraint only if benchmarks on both fail to meet the quality bar.

6. Distribution: Bundled

Model ships with the game install. No optional download step. ~1.5GB added to install size is acceptable.

7. Hardware Detection: Layered

• Layer 1: CPU/RAM check — can the model even load?
• Layer 2: Time-per-token benchmark on first enable — is inference fast enough to be useful?
• Layer 3: Recommendation to disable if below threshold, but player can always override
• No hard minimum spec floor. If they're patient, let them run it.
• Always an option to disable ("AI-Enhanced Dialogue" toggle).

8. No Minimum Spec Floor

The question isn't "what hardware do we refuse to run on" — it's "when do we recommend turning it off." The system runs on anything that passes the RAM check; the recommendation threshold handles the rest.