diff --git a/docs/backups/settledreach.db.backup b/docs/backups/settledreach.db.backup
index 30bdfde72..00b92db41 100644
Binary files a/docs/backups/settledreach.db.backup and b/docs/backups/settledreach.db.backup differ
diff --git a/docs/sprints/sprint-25/copy.md b/docs/sprints/sprint-25/copy.md
new file mode 100644
index 000000000..d4dc48b9b
--- /dev/null
+++ b/docs/sprints/sprint-25/copy.md
@@ -0,0 +1,60 @@
+# Sprint 25: Emerge — Copy Tasks
+
+**Goal:** Prove the generator can extrapolate from minimal input — a rural Krenn village from zone type and culture profile alone, no per-location spec.
+
+**Branch:** `copy`
+**Agents:** Miri (worldbuilding lead), Mellanie (voice/dialogue review)
+
+## New Tickets
+
+| # | Title | Blocked by |
+|---|-------|------------|
+| #609 | Zone identity spec | — |
+| #610 | Krenn culture profile | — |
+
+Use `tooling/db/ticket show <id>` for full details.
+
+## Key Decisions
+
+- `decisions/scope.md` — D-114 (generator-first proof-of-life), D-119 (generator spike critical path)
+- `decisions/content.md` — D-121 (voice is culture-driven, job as modifier), D-122 (all NPCs generated), D-128 (culture implicit in starting location), D-129 (NPC personality: traits + behavior first)
+- `decisions/architecture.md` — D-012 (chunk-based map, borderless generation future)
+
+## Notes
+
+**#609 — Zone identity spec**
+
+- Output: a YAML or Markdown document defining zone type taxonomy for the Settled Reach's social vocabulary.
+- What each zone TYPE means (not a specific location): urban residential, rural agricultural, industrial transit, informal/fringe, commercial, etc. What does each feel like? Who lives or works there? What emotional register does it carry? What is the density, pace, noise level?
+- This is a general taxonomy — NOT a spec for a specific village. The generator needs the zone types as input parameters so it can extrapolate any location.
+- Downstream consumers: Tyre (generator zone template parameters for #611/#612), Araminta (zone visual grammar), Mellanie (culture-primary voice cards).
+- File location: `content/global/zone-identity-spec.md` (or YAML if preferred — coordinate with Tyre on what format #611 needs to ingest).
+- Krenn System context: check `decisions/content.md` D-036 amendment and D-128. Station Sova's districts (D-093) are an example of zone types in action but the spec must generalize beyond Sova.
+
+**#610 — Krenn culture profile**
+
+- Output: one full culture profile for Krenn System / Station Sova, usable as generator input constraints and AI content templating prompt seeds.
+- Must encode: naming conventions and phonemes, speech patterns and registers (formal/informal), economic values and class markers, attitudes toward work/leisure/authority, sensory palette (what Krenn space looks/smells/sounds like), social norms and taboos, dress and appearance codes.
+- D-128: culture is implicit in starting location. This profile IS the cultural context for every generated NPC in the Krenn System — not just flavor text.
+- D-121: voice is culture-driven, job modifies. The culture profile must be specific enough that Tyre can use it to constrain generated NPC voice parameters.
+- D-123: this profile feeds the AI content templating pipeline. Culture vectors = prompt constraints. The profile must be concrete enough to function as a constraint, not just atmospheric description.
+- File location: `content/global/culture-krenn.md` (or YAML — coordinate with Tyre).
+- Existing Sova atmosphere notes live in `decisions/content.md` D-036 (amended post-workshop). Pull from those but go deeper on cultural mechanics.
+
+## Dependency Chain
+
+```
+#609 (zone identity spec) ──┐
+                            ├──> server #611 (NpcBlueprint struct)
+#610 (Krenn culture profile)┘        └──> #612 (template gen) ──> #613 (NPC pipeline)
+```
+
+Copy deliverables (#609, #610) are prerequisites for all server work in this sprint. Both can be written in parallel — they are independent of each other.
+
+## PR Workflow
+
+When ready to submit, create a PR with `tea` CLI. All flags are required to avoid TTY prompts (see CLAUDE.md "Gitea access" section):
+
+```bash
+tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "feat(copy): zone identity spec and Krenn culture profile" --description "body" --base main --head copy
+```
diff --git a/docs/sprints/sprint-25/joint.md b/docs/sprints/sprint-25/joint.md
new file mode 100644
index 000000000..5f5aec037
--- /dev/null
+++ b/docs/sprints/sprint-25/joint.md
@@ -0,0 +1,100 @@
+# Sprint 25: Emerge — Joint
+
+**Goal:** Prove the generator can extrapolate from minimal input — a rural Krenn village from zone type and culture profile alone, no per-location spec.
+
+## Pre-Sprint
+
+| Item | Owner | Blocks |
+|------|-------|--------|
+| Coordinate output format for zone identity spec (#609) | Miri + Tyre | #611 |
+| Coordinate output format for culture profile (#610) | Miri + Tyre | #611, #612 |
+| Confirm `NpcBlueprint` file location and module wiring | Tyre | #612, #613 |
+
+The critical coordination question: does copy deliver YAML files (which the generator reads at runtime) or Markdown design documents (which Tyre reads and encodes into Rust)? Either works — decide at sprint start. YAML is preferred if Tyre can define a schema upfront; Markdown if the profile needs to be free-form first and codified later.
+
+## Sprint Completion Proof — Throwaway Render
+
+**This is not a test suite. It is an eyeball test.**
+
+The proof is a single standalone invocation that feeds the generator minimal parameters and inspects the output for shape and coherence.
+
+**Input (the minimum the generator must accept):**
+```
+zone_type: "rural"
+region: "outside Sova urban zone"
+system: "Krenn"
+seed: 42
+```
+
+Plus the Krenn culture profile (#610) and zone identity taxonomy (#609) — loaded from disk, not hardcoded.
+
+**NO location-specific spec.** No "the village has a tavern." No bespoke social site list. The generator extrapolates entirely from zone type + culture.
+
+**Command (to be written as part of #612):**
+```bash
+cargo run --bin generator-spike -- --zone rural --seed 42
+```
+
+**Expected output (printed to stdout):**
+1. `DistrictSkeleton` summary: zone type, block count, social site placements
+2. Generated NPC list: one line per NPC with name, role, 2-3 traits, one observable behavior
+3. A sample relationship pair (NPC A knows NPC B as X)
+
+**The pass condition (human judgment, not automated):**
+- Does the output have *shape*? A rural area should feel different from an industrial one.
+- Does it feel like it *belongs in the Krenn System*? Not generic space-village. Krenn-inflected.
+- Can you read the NPC relationships from the output? Not infer — *read*.
+
+**The fail condition:**
+- Output could be from any game in any setting (culture profile not doing work)
+- All rural areas produce identical outputs with different names (zone type not doing work)
+- NPC traits are unreadable from text (legibility fails — D-129 gate not met)
+
+**Why this framing matters (from the approval discussion):**
+The sprint proof deliberately uses minimal input because the generator's entire value proposition is scaling beyond hand-authored content. If it only works with detailed per-location specs, it fails the brief — because the whole point is the player walking into an unspecified area and it still having shape. The "throwaway render" framing is intentional: this is a rough proof, not a polished demo. Pass/fail is a 5-minute eyeball by the team lead.
+
+## Tickets by Team
+
+| Team | # | Title |
+|------|---|-------|
+| copy | #609 | Zone identity spec |
+| copy | #610 | Krenn culture profile |
+| server | #611 | NpcBlueprint struct design |
+| server | #612 | Template assembly generator |
+| server | #613 | NPC generation pipeline |
+
+## Dependency Chain
+
+```
+copy #609 (zone spec) ──┐
+                        ├──> server #611 (NpcBlueprint) ──> #612 (template gen) ──> #613 (NPC pipeline)
+copy #610 (culture) ───┘
+```
+
+Copy (#609, #610) runs in parallel and completes first. Server (#611 → #612 → #613) runs sequentially after copy delivers.
+
+## Open Questions
+
+| ID | Question | Blocking |
+|----|----------|---------|
+| Q-WTF-033 | AI templating: Claude API, local ollama, or manual for v0.2? | #613, #623 |
+| Q-WTF-039 | Character creation screen: portrait render or tile-scale preview? | Sprint 26+ |
+| Q-WTF-040 | Do creation choices trace into the generated apartment? | Sprint 26+ |
+
+Q-WTF-033 is the most relevant to this sprint. #613 does not need to implement AI templating — that is #623 (deferred). But the pipeline should be designed so AI templating slots in later without a rewrite. Discuss at sprint start.
+
+## Deferred to Future Sprints
+
+- Tycoon bookmark (#605, #614-617) — needs generator output proven first
+- Character creation screen (#606, #618-620) — client work, post-generator
+- NPC legibility systems (#607, #621-622) — downstream of generator
+- AI content templating (#623) — Q-WTF-033 unresolved
+- World feel systems (#608, #624-626) — downstream of everything
+- Visual rendering of generated world — out of scope for this spike
+
+## What This Sprint Does NOT Do
+
+- No client work (no rendering of generated content)
+- No new content authored beyond the zone spec and culture profile
+- No AI templating implementation (design for it, don't build it)
+- No playable session from the generated world
diff --git a/docs/sprints/sprint-25/server.md b/docs/sprints/sprint-25/server.md
new file mode 100644
index 000000000..719a9f835
--- /dev/null
+++ b/docs/sprints/sprint-25/server.md
@@ -0,0 +1,77 @@
+# Sprint 25: Emerge — Server Tasks
+
+**Goal:** Prove the generator can extrapolate from minimal input — a rural Krenn village from zone type and culture profile alone, no per-location spec.
+
+**Branch:** `server`
+**Agents:** Dudley (simulation dev), Tyre (architect)
+
+## New Tickets
+
+| # | Title | Blocked by |
+|---|-------|------------|
+| #611 | NpcBlueprint struct design | #609 (copy), #610 (copy) |
+| #612 | Template assembly generator | #609, #610, #611 |
+| #613 | NPC generation pipeline | #611, #612 |
+
+Use `tooling/db/ticket show <id>` for full details.
+
+## Key Decisions
+
+- `decisions/scope.md` — D-114 (generator-first proof-of-life), D-119 (generator spike critical path), D-115 (skills + bookmark only for creation)
+- `decisions/content.md` — D-122 (all NPCs generated), D-128 (culture implicit in location), D-129 (NPC personality: traits + behavior first), D-121 (voice culture-driven), D-123 (AI content templating via culture vectors)
+- `decisions/architecture.md` — D-012 (chunk-based map, borderless generation future)
+
+## What Exists
+
+- **`server/src/simulation/generator.rs`** (576 lines) — `DistrictSkeleton` data model, `DistrictType`, `ZoningType`, `SocialSitePlacement`, `TriangleAssignment`, `BlockSkeleton`. This is the Phase 1 *data model* — struct definitions for what a generated district looks like. The *generator logic* that produces these structs from input parameters does not yet exist.
+- **`server/src/npc/generate.rs`** — existing NPC generator taking a `RoleDefinition` (the 10-axis model: Want, Secret, Relationships, Tolerance, DailyRoutine, InformationInventory, Contentment, PersonalityTraits, TellSystem, SkillSet). Generates a fully-populated NPC entity via `SimRng` (deterministic, seeded). Sprint 25 work extends this pipeline, it does not replace it.
+- **`server/src/npc/`** — full NPC component set: `awareness.rs`, `background.rs`, `disclosure.rs`, `generate.rs`, `interaction.rs`, `mod.rs`, `mood.rs`, `relationships.rs`, `routine.rs`, `tell_state.rs`, `tolerance.rs`, `trait_modifiers.rs`, `vision.rs`.
+- **`server/src/content/`** — content loading: `entanglement.rs`, `hot_reload.rs`, `instantiation.rs`, `line_pool.rs`, `loader.rs`, `spawn.rs`, `template.rs`, `types.rs`.
+
+## Notes
+
+**#611 — NpcBlueprint struct design**
+
+- Blocked by #609 and #610 (copy team delivers these first). Read those documents before writing the struct.
+- This struct is the *interface* between the generator and all downstream systems: rendering, voice, AI templating, simulation.
+- Must encode: trait set (from D-129), observable behavior surface (what a bystander can read), relationships (Sims + Rimworld style per D-129), role/occupation, cultural markers (feeds D-121 voice pipeline and D-123 AI templating), zone-type affiliation.
+- The existing `RoleDefinition` in `npc/generate.rs` covers the 10-axis model. `NpcBlueprint` is a higher-level generator output that wraps role + cultural context + zone parameters. Think of `RoleDefinition` as "what the generator uses internally" and `NpcBlueprint` as "what the generator exports."
+- Write the struct in `server/src/npc/blueprint.rs` (new file). Add a D-record reference in `decisions/architecture.md` or `decisions/content.md` when the struct is settled.
+- Must be serializable (Serde) for inspection output (the sprint proof dumps the blueprint JSON to stdout).
+
+**#612 — Template assembly generator**
+
+- Blocked by #609, #610, #611.
+- Input: zone type parameter (from zone identity spec), culture profile (from Krenn culture profile), seed (u64). No per-location spec. The whole point is extrapolating from minimal input.
+- Output: a `DistrictSkeleton` (already defined in `server/src/simulation/generator.rs`) with `SocialSitePlacement` entries populated and `NpcBlueprint`s attached to each role slot.
+- NOT procedural geography — template assembly. The generator picks a zone template from the zone identity taxonomy and fills it. The template provides the shape; the culture profile and seed provide the variety.
+- Write generator logic in `server/src/simulation/generator.rs` (add below existing structs) or extract to `server/src/simulation/template_assembly.rs` — architect's call.
+- The generator must be callable standalone (not as a bevy system) for the sprint proof (see joint.md).
+- Determinism: use `SimRng` (ChaCha20, existing in `server/src/simulation/rng.rs`). Same seed + same zone type + same culture profile → same output.
+
+**#613 — NPC generation pipeline**
+
+- Blocked by #611 and #612.
+- Wire the template generator output into actual NPC entity spawning.
+- Input: `DistrictSkeleton` with `NpcBlueprint`s → spawn ECS entities using the existing `npc/generate.rs` pipeline, extended to accept cultural markers from the blueprint.
+- The existing `RoleDefinition` in `npc/generate.rs` needs a cultural marker field (or the blueprint drives trait selection to match the culture profile).
+- Proof-of-life test (in the sprint proof): print generated NPC trait sets and observable behaviors to stdout. A human reading the output should be able to say "yes, this NPC could plausibly exist in the Krenn System."
+- D-129: traits + behavior first. The proof gate is not rendering — it is legibility from text output alone.
+
+## Dependency Chain
+
+```
+copy #609 (zone spec) ──┐
+                        ├──> #611 (NpcBlueprint) ──> #612 (template gen) ──> #613 (NPC pipeline)
+copy #610 (culture) ───┘
+```
+
+Server work begins when copy delivers #609 and #610. #611 must be complete before #612 starts. #613 follows #612.
+
+## PR Workflow
+
+When ready to submit, create a PR with `tea` CLI. All flags are required to avoid TTY prompts (see CLAUDE.md "Gitea access" section):
+
+```bash
+tea pr create --repo jpmschweitzer/settled-reach --login schweitz --title "feat(simulation): generator spike — NpcBlueprint, template assembly, NPC pipeline" --description "body" --base main --head server
+```