---
title: "Round 3 Inputs"
description: "Binding decisions from Jeroen after rounds 1-2 as inputs for round 3"
type: workshop
status: archived
workshop: llm-voice-pipeline
agent: ""
round: 3
created: 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.