settled-reach/docs/workshops/wheres-the-fun/round5-gestalt.md

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

title	description	type	status	workshop	agent	round	created
Round 5: GESTALT — Systems Design Reaction to 15 Locked Decisions	Gestalt's systems design reactions to the 15 locked decisions	workshop	archived	wheres-the-fun	gestalt	5	2026-03-05

Round 5: GESTALT — Systems Design Reaction to 15 Locked Decisions

Where's the Fun? Workshop | 2026-03-05

Agent: GESTALT (Systems Design) Based on: Round 4 interview transcript, interview supplement, all Round 4 agent outputs

---

Let me break down what these 15 decisions actually mean mechanically. Crack knuckles. Some of these are clean. Some of them open new design work I wasn't expecting. And one pair of decisions is in tension that nobody has flagged yet.

---

Part 1: Decision-by-Decision Mechanical Analysis

Decision 1 — Proof-of-life = generator + graphics

This is the single most scope-altering decision in the batch, and I don't think its full weight has landed yet.

Jeroen explicitly rejected the reasoning that led to v0.1's narrow scope. The proof-of-life is NOT a hand-built Sova Transit with authored NPC routines. It IS the generator running at reasonable scale + legible characters. That means Tyre's Tier A ("hand-built, different map every time but same district character") is off the table. We need at minimum Tier B (template-generated locations, archetypes populated by rules).

What this means mechanically:

The 14 D-records from the Generator Architecture workshop are now load-bearing for v0.2. The generator isn't a v0.3 feature we're planning toward — it's the v0.2 deliverable. Every other system (NPC legibility, career bookmarks, the apartment) is built ON TOP of the generator, not instead of it.

This also means Decision 7 (all NPCs generated) and Decision 1 are the same pipeline, not two separate problems. The generator produces: locations → zones → NPC populations. The NPC archetypes fill roles based on zone characteristics. The generator IS the NPC generation system.

Implementation risk: The generator-first approach defers the "is the life-sim fun?" validation. We won't have a playable first-run experience until the generator is producing legible space. If the generator takes 4-6 sprints (Tyre's Tier B estimate), the first "does this feel like a game" moment is sprint 28-30. That's the v0.1 mistake in a different form — building foundation before testing the experience layer.

Flag: This is a real tension between Decision 1 (generator first) and the principle of "smallest possible proof before full vision." I'm not saying Jeroen is wrong — the generator IS the vision, not an optimization. But someone should be tracking when the first playable proof moment arrives in the generator-first roadmap.

---

Decision 2 — Skills + bookmark only for character creation

Clean and right for scope. Family/culture/religion deferred.

What this means mechanically:

The character creation system for v0.2 needs: (1) skill point allocation across proficiencies, (2) career bookmark selection. That's it.

But Decision 6 (voice is culture-driven) creates a tension I need to flag. See Part 2 below.

Skill proficiency list: The supplement names shooting, social manipulation, hacking, mechanical repair. The tycoon bookmark (Decision 4) probably leans on social manipulation and possibly hacking (for insert operations). Shooting and mechanical repair are secondary. Does "skills + bookmark" mean all four proficiencies are available to allocate regardless of bookmark, or does the bookmark constrain which skills are relevant? This needs a spec.

---

Decision 3 — Religion is NOT a game system

Removed. No mechanical footprint. No action required.

---

Decision 4 — Tycoon is the v0.2 bookmark

This decision resolves the Tyre/Ozzie dispute about law enforcement vs smuggler by going in a completely different direction. Zero investigation content. Tycoon.

What this means mechanically:

The entire verb ecosystem I was preparing to spec needs to start from scratch with tycoon verbs. What does a tycoon DO, action-by-action?

I don't have a spec for this. Nobody does. This is the first concrete design work needed for v0.2.

My initial tycoon verb map:

Context	Primary Verb	Secondary Verbs	VerbPriorityProfile default
Approaching an NPC (business)	Negotiate	Examine, Talk, Observe	Negotiate > Examine > Talk > Move
Approaching an NPC (social)	Talk	Observe, Move	Talk > Observe > Move
Approaching a location (economic)	Invest	Inspect, Inquire	Invest > Inspect > Inquire
Insert use (remote)	Monitor	Adjust, Transfer	Monitor > Adjust
Gig contract (one-off deal)	Accept	Examine, Decline	Accept > Examine > Decline

This is a first pass, not a spec. The tycoon VerbPriorityProfile is the first thing I need to design before any downstream work can proceed.

Tycoon career model synthesis: The decision notes that tycoon blends Active (manage business), WFH (remote investments via insert), and Gig (one-off deals). This is the first bookmark that explicitly touches all three career model rhythms. Mellanie's concern about three monologue cadences is therefore relevant to the tycoon specifically — the tycoon isn't one rhythm, it's three rhythms in one career. That's elegant if designed intentionally, but complex if not.

---

Decision 5 — Skills affect outcome (mostly C)

My Round 4 Q1 is answered. This is the right answer and I endorse it.

What this means mechanically:

What doesn't change	What changes
Verb computation: skill-agnostic (same verbs appear)	Resolution layer: skill score modifies success rate
VerbPriorityProfile: career-determined, not skill-determined	Advanced verb exceptions: some verbs gated by minimum skill
Content authoring: one verb pool per context	Outcome authoring: branching based on skill-modified results

The "mostly C" caveat — some advanced verbs may be gated — is the one area that needs a bounded spec before implementation. If "advanced verb gating" is left unspecified, individual verb authors will make ad hoc decisions and we'll have a mix of outcome-only and availability-gated verbs with no consistent player mental model.

Flag: Write the advanced-verb gating spec in Sprint 25 or 26, before individual verb specs are authored. Proposed rule: a verb is gated only if using it without the required skill would produce a nonsensical interaction (e.g., "Hack" with zero hacking skill is just failing at something you don't understand — the failure itself is incoherent as gameplay). Most social, economic, and movement verbs should stay ungated.

---

Decision 6 — Voice: culture-driven, job modifies

The inversion: This decision inverts the assumed architecture. Culture is the primary voice register; job is the modifier layer. A Van Maanen's Star tycoon sounds like a Van Maanen's Star person who runs businesses.

What this means mechanically:

The voice card hierarchy is:

Culture (base register)
  └── Job modifier (adds professional vocabulary and priority concerns)
       └── Situation triggers (fires the appropriate line)

This is clean. But it creates a tension with Decision 2.

The tension: Decision 2 defers culture selection from character creation. Skills + bookmark only. If culture is the primary voice register but the player hasn't selected a culture, what base register does the voice card use?

Resolution options:

Option	Mechanic	Tradeoff
A — Bookmark implies culture	Tycoon bookmark defaults to a cultural context (e.g., Burnelli economic culture)	Simple, but cultural identity is defined by career, not creation
B — Culturally neutral Phase 1 voice	The voice card runs without culture modifier until culture is added	Voice feels generic in v0.2
C — World assigns culture at generation	The apartment generation places the player in a cultural context; voice card reads that	Elegant but requires generator to have cultural zones in v0.2
D — Single culture in v0.2 scope	Only one cultural context is populated in v0.2; the culture/job distinction is architectural but effectively single-valued	Simplest, works for v0.2, leaves the architecture right for v0.3

Option D is probably the right v0.2 answer. Mellanie writes one culture-base voice card + tycoon modifier. The architecture is culture-primary, but with only one culture active, the distinction is invisible. When culture selection is added later, the system expands naturally.

This needs confirmation. See Questions for Jeroen below.

---

Decision 7 — ALL NPCs generated, no named characters

Kael doesn't exist. The smuggler's FRIEND is now a role template. This decision has cascading content architecture implications but the mechanical implications are actually simpler than I expected.

What this means mechanically:

Before	After
FRIEND = Kael Davan (hand-placed)	FRIEND = role assigned by generator based on position + proximity
Monologue references Kael by name	Monologue templates with role-reference slots ([FRIEND.name], [FRIEND.role])
Phase Zero authored for a specific person	Phase Zero authored for a role archetype
Consequence engine tracks Kael-specific states	Consequence engine tracks role-states

For the VerbPriorityProfile: no change. Verbs are context-aware, not NPC-aware. The fact that an NPC is generated vs hand-authored is invisible to the verb system.

For the relationship system: the generator assigns a generated NPC to the FRIEND-figure role. The relationship system tracks warmth accumulation with that NPC-ID. The FRIEND pattern (warmth accumulation → Phase Zero completion → arc gates unlock) works identically whether the NPC is Kael or [Generated-ID-4729].

Interesting emergent design question: What determines which generated NPC gets assigned to the FRIEND-figure role? Presumably: proximity to the player's starting location, appropriate social position for the career (a tycoon's FRIEND-figure might be a key supplier or a fellow small-business owner in the district), and some relationship-formation opportunity (overlapping schedules, shared location). This is a generation rule I don't see specified anywhere. It belongs in the zone identity spec Miri is building.

---

Decision 8 — Generative AI for NPC content templating

Opens the content pipeline to AI-assisted generation. Culture vectors + tone + accents as templating dimensions.

What this means mechanically:

The content pipeline for NPC dialogue becomes:

Template (FRIEND-figure warmth, line pool type, trigger context)
  → AI parametrization (culture vector, tone, accent prompts)
  → Generated line pool
  → Trigger system (fires appropriate lines on game events)

This is different from Mellanie's current pipeline, which authors individual lines directly. The template layer is new infrastructure.

For v0.2: "Limited vocabulary acceptable at first" means we can start with a small template set and a small generated pool. The architecture should support expansion; the initial scope should be deliberately narrow.

Implementation note: The AI generation step doesn't have to happen at runtime in v0.2. Generate the line pool offline (using the template + AI), bake the results into the game data, ship them. In-game ollama (Decision 9) is for future runtime generation. The pipeline distinction matters for sprint scoping.

---

Decision 9 — Possible in-game ollama (deferred but open)

No design work required in v0.2. But note the architectural implication:

If in-game ollama is ever implemented, the NPC dialogue system needs to be able to call it asynchronously without blocking the main game loop. When the time comes, this is a Tyre/server concern: dialogue requests need to be non-blocking, results cached, and the simulation tick should not wait on LLM inference.

Flag this as an architectural constraint to keep in mind, not a v0.2 implementation item.

---

Decision 10 — Quietly responsive world, not indifferent

Gore's Kenshi-indifference premise rejected. The world notices locally. Gradient: world → district → neighbors → colleagues → friends.

What this means mechanically:

This isn't just a content decision — it's a simulation behavior decision. The "quiet responsiveness" Jeroen describes (prices shift when you buy, NPCs mention you were there yesterday) isn't authored content arriving in Phase 2. It's Phase 1 simulation behavior.

Systems that produce quiet responsiveness:

System	Behavior	Complexity
Economy tick with local price elasticity	Buying from a vendor shifts that vendor's prices for a period	Low — add price elasticity factor to economy tick
NPC short-term memory	NPCs log recent player encounters; surface this in greetings after threshold	Medium — NPC state component, decay timer
Relationship proximity accumulation	Repeated location sharing accumulates a "familiarity" score	Low — already part of relationship system
District reputation	Local actions visible to district NPCs aggregate into a district-level known status	Medium — reputation component, district-scoped

These belong in Phase 1 server work, not Phase 2 authored content. The Phase 1 world needs these simulation behaviors to produce the "latent responsiveness" Gore correctly identified as necessary before Phase 2 consequence weight can land.

The gradient design:

World (global)        → Faction reputation (very slow, very public actions only)
District (local)      → District reputation (consistent presence, notable actions)
Neighbors/colleagues  → Relationship warmth (regular interaction)
FRIEND-figure         → Deep relationship state (Phase Zero accumulation)

This gradient is the map of what the consequence engine tracks. The storyteller reads this gradient when deciding whether to inject pressure.

---

Decision 11 — Full character customization

Hair, clothing, colors. Readability through outline/highlight, not by limiting customization.

What this means mechanically:

The character creator needs appearance variables: hair type, clothing type, color palettes. These are distinct from the NPC archetype system. NPCs are legible through archetype-silhouette + behavioral state (Araminta's system). The player character is legible through their custom appearance + career insert visual grammar.

No systems change needed beyond the character data model gaining appearance fields. The tile renderer already handles visual output. The outline/highlight solution is a visual design choice, not a systems architecture choice.

---

Decision 12 — Setting delivery: both layers (visual + insert)

Visual shows it; insert names and contextualizes. Parallel production tracks.

What this means mechanically:

The insert becomes the primary setting delivery mechanism for information the physical world can't show. Zone type, NPC names, prices, your own economic state — these come through the insert, not through ambient world reading.

For systems design, the insert is a designed UI system that reads from the observer snapshot. The insert's information content is career-filtered: a tycoon insert shows economic data, a law enforcement insert shows procedural data. The snapshot must carry enough world-state for the insert to populate correctly.

This is already part of the diegetic tool suite design. The tycoon insert is the first one we need to spec for v0.2.

---

Decision 13 — First Settled Reach moment: apartment + insert activation

Two moments. Before you leave the room.

What this means mechanically:

Two scripted events, fired in sequence on first session:

1. Apartment generation: The world generator places the player in housing appropriate to their starting economic state. For tycoon: moderate standing (not wealthy, not destitute — you're building, not arrived). The apartment READS as your economic position through visual density, furnishing quality, view of the district.

2. Insert activation: A designed UI event. The insert powers on, career UI appears for the first time. The tycoon insert activates with its economic dashboard. This is simultaneously: setting delivery (the insert contextualizes where you are), career identification (your economic tools are real, you're a tycoon), and tutorial (through use, not instruction).

Design question: What drives the apartment's economic class in character creation if we only have skills + bookmark? The tycoon bookmark probably defaults to a moderate economic starting state. But can the player influence this through skill allocation? A character with high social manipulation might start with better social connections (smaller apartment but better district) vs high hacking (better tools, worse physical space). This is flavor if skills are outcome-only (Decision 5 says mostly C), but it's the kind of detail that makes character creation feel like it matters.

---

Decision 14 — Groundhog Day alarm clock homage

First day only. Click pa-pa pa-pa, cut short. "New day, new start, new chances."

What this means mechanically:

One-shot event: first_session_day_1 = true. The alarm fires on Day 1, game boot 1. After that, it's a standard day-start notification (or silence — the routine has absorbed it).

This is the authored beat that opens Phase Zero. Miri notes correctly that the day_start trigger type is needed for the monologue system. The very first monologue line should fire here — establishing the character's voice before any world interaction has occurred.

The Groundhog Day structure (alarm → calendar ping → appointment) is the authored scaffolding that teaches the tycoon bookmark through the first day's rhythm. This is the "rails to take off from" (Decision 15) — the authored first beat, then agency.

---

Decision 15 — Player choices ARE the content (Rimworld model)

This is the philosophical foundation that changes what several other systems need to do.

What this means mechanically:

There is no formal mission system. There is no quest tracker. There is no objective list. The job (tycoon) provides a context (I'm building a business) and access to tools (economic verbs, insert dashboard). Everything that happens is a consequence of player choices within that context.

The consequence engine (CauseChain tracking) becomes the primary authored system. The storyteller's job is pressure calibration: when to inject authored pressure (the ring needs a new supplier — the tycoon is approached), when to let quiet days run.

What "a job is rails to take off from" means architecturally:

What the job provides	What it doesn't provide
VerbPriorityProfile (economic verbs salient)	Objectives or tasks to complete
Diegetic tools (insert dashboard, investment terminal)	Quest markers or waypoints
Starting location and FRIEND-figure context	A pre-authored narrative thread
Income tick and economic foothold	A tutorial beyond the first day
Asymmetric lens (what the tycoon sees vs others)	The story — the player makes the story

The storyteller reads the simulation state and injects opportunities: an NPC approaches with a deal, a district event creates an economic opening, a relationship threshold triggers a new interaction possibility. The player decides what to do with those opportunities.

The consequence engine scope question: If every player choice is potentially content, what does the CauseChain track? In a mission-based game, this is clear (mission decisions are trackable events). In the Rimworld model, the CauseChain needs to recognize which player actions are "consequential" — worth tracking for future reference. I don't have a spec for this. See Questions for Jeroen.

---

Part 2: Tensions and Contradictions

Tension 1: Culture-driven voice + deferred culture selection

Decisions in tension: Decision 6 (culture-driven voice) + Decision 2 (culture deferred from character creation).

The problem: Voice is culture-primary. But the player doesn't select culture in v0.2. The voice card has a base register it can't derive.

My recommendation: Decision D (single cultural context in v0.2, architecture is correct but single-valued). Design the voice system to accept a culture parameter. For v0.2, hardcode one value. When culture selection arrives in v0.3+, the system already supports it. This costs nothing architecturally and costs Mellanie one voice card instead of many.

But this needs explicit confirmation — because if Jeroen means the tycoon bookmark IS a cultural statement (tycoons in this world are Burnelli-economic in register by definition), then culture comes through the bookmark and the tension dissolves differently.

---

Tension 2: Generator-first proof-of-life vs earliest-possible playtest

Decisions in tension: Decision 1 (proof-of-life = generator + graphics) vs the v0.1 lesson (we built too much before testing the fun hypothesis).

The problem: Tyre's Tier A (hand-built world, 2-3 sprints, first playtest by sprint 28) is rejected. Tier B (template-generated) is the minimum. That means the first playable proof is later.

I am not recommending against Decision 1 — the generator IS the vision and Jeroen is right that testing on a hand-built world proves nothing about the generator. But I want to flag: the team should have a planned "first playable state" moment in the generator-first roadmap. What does the first thing you can actually play look like, and when does it arrive? If that's sprint 30, that's fine — but it should be planned, not discovered.

---

Tension 3: "Quietly responsive" requires Phase 1 simulation work, not just authored content

Decisions in tension: Decision 10 (quietly responsive world) + Decision 15 (player choices are the content, Rimworld model).

The problem: If the Phase 1 world is designed to be quietly responsive (prices shift, NPCs remember), that responsiveness must be built into the simulation — not delivered through Phase 2 authored content injection. The Rimworld model's storyteller handles dramatic pressure injection, not ambient world responsiveness. These are two different systems:

• Storyteller: When does authored content arrive? How intense is it? (Phase 2)
• Ambient responsiveness: The simulation's baseline consequence behavior. (Phase 1)

If we assume "quietly responsive" is delivered by the storyteller's authored content, we'll get Phase 1 as a tech demo that feels unresponsive until Phase 2 content arrives. Gore correctly identified this as the emotional register risk. The fix is simulation-level, not content-level.

Action required: The Phase 1 server work plan needs to include the ambient responsiveness behaviors (price elasticity, NPC memory, familiarity accumulation) as simulation features, not as authored content placeholders.

---

Tension 4: "Mostly C" skills + "some verbs gated" = unspecified exception surface

Decision in tension: Decision 5 ("mostly C" with unspecified gated exceptions).

The problem: "Mostly C" with exceptions that need a spec is a design debt item. It sounds minor but it's actually a correctness invariant: the player's mental model of "I can always try anything" is violated every time they encounter a gated verb without understanding why. Inconsistent gating is more confusing than either full gating or no gating.

Action required: Before any verb specs are authored, define the gating rule. My proposed rule: a verb is gated only when the action is incomprehensible without the required capability (not just ineffective — the action doesn't make sense). "Hack a terminal with zero hacking skill" = nonsensical, gate it. "Negotiate poorly with low social skill" = meaningful failure, don't gate it.

---

Part 3: Implementation Risks

Risk 1: Tycoon verb design is a blank page

The highest priority new design work for v0.2. We have zero designed tycoon verbs, zero tycoon VerbPriorityProfile, zero tycoon economic interactions. All previous verb work (smuggler, law enforcement) is irrelevant to the v0.2 scope. This needs to be the first concrete design session.

Who needs this: Tyre (verb computation), Araminta (verb prompt visual treatment), Mellanie (trigger catalog tied to verb outcomes), Ozzie (first day design needs tycoon-specific tools).

---

Risk 2: NPC generation rules are upstream of everything

The generator needs to know what NPC archetypes exist and what roles they fill in each zone type. This isn't Miri's zone identity spec alone — it's the intersection of zone identity + NPC archetype design + role assignment rules. If this spec doesn't exist before the generator runs, the generator produces either no NPCs or random NPCs that don't fit the world.

The spec needs:

• Zone types and their NPC archetype distributions
• Which archetypes can fill which roles (FRIEND-figure, competitor, supplier, customer...)
• What physical and behavioral characteristics mark each archetype
• The assignment algorithm for FRIEND-figure role selection

This is a joint spec: Miri (zone identity + cultural meaning), Gestalt (role taxonomy + assignment rules), Araminta (behavioral and visual markers per archetype). One document, three contributors.

---

Risk 3: The consequence engine scope for a mission-less game

Without a formal mission system, the CauseChain system has no obvious boundary for what it tracks. In the Rimworld model, every player action is potentially a seed for future consequences. But the CauseChain system can't log everything — it needs a selective definition of "consequential action."

Proposed initial scope (to be confirmed):

• Economic transactions above a threshold (large investments, major deals)
• NPC relationship-state changes (first meeting, relationship threshold crossings, conflict events)
• World-state changes triggered by player actions (taking or losing a business asset, district reputation changes)
• Storyteller-injected events (authored pressure that the player responds to)

This is a fraction of all player actions, but it captures the events that are likely to produce future consequence. The risk is under-tracking (important seeds are missed) or over-tracking (performance and signal-noise problems).

---

Risk 4: The apartment generation requires economic class data at character creation

Decision 13 says the apartment reflects the player's economic position. Decision 2 says character creation is skills + bookmark only. What economic starting state does the tycoon bookmark imply?

If the tycoon bookmark has a fixed economic starting state, the apartment generation is straightforward. If skills can influence starting economic state (high social = better connections, better starting district), the apartment generation becomes a function of character creation parameters.

This needs to be specified before the apartment generator is built. It's a small decision but it affects both the character creator (what does skill allocation change?) and the world generator (what economic class input does the apartment generation take?).

---

Part 4: Questions for Jeroen

QUESTION FOR JEROEN 1: How does the tycoon bookmark engage with culture in v0.2?

The tension: Decision 6 says voice is culture-driven. Decision 2 defers culture from character creation. The voice system needs a base culture register to operate.

The concrete question: For v0.2 with the tycoon bookmark as the only career:

• Does the tycoon bookmark imply a cultural register (tycoons in this world are economically Burnelli-adjacent by definition, so picking tycoon picks your voice base)?
• Or is the v0.2 culture layer simply "one culture, not selectable," with the culture/job distinction existing architecturally but invisible until culture selection is added?
• Or is there a third option — the world generator places you in a culturally specific starting zone (culture comes from the world, not creation), and the voice card reads the zone's cultural context?

Why it matters now: Mellanie can't write voice cards until she knows whether to write one culture-base + tycoon modifier, or to write a parametric template, or to write the tycoon voice as culturally neutral until culture is added. The answer changes her production scope significantly.

---

QUESTION FOR JEROEN 2: What does a tycoon DO at the verb level?

This is the most urgent design gap. We've confirmed tycoon as the v0.2 bookmark. But we have zero designed tycoon verbs, zero VerbPriorityProfile, zero economic interactions specified.

The concrete question: When a tycoon player approaches an NPC in the world, what is the default action offered? What economic interactions look like at the verb level? Is "Negotiate" a single verb that encompasses deal-making, or is there a vocabulary of economic verbs (Invest, Hire, Sell, Buy, Inspect, Verify)?

And for the tycoon's world footprint: who are the NPC types the tycoon primarily interacts with? Suppliers, customers, competitors, district officials, financiers? The VerbPriorityProfile needs to know what the tycoon's world looks like from a verb interaction standpoint.

Why it matters now: The tycoon VerbPriorityProfile is the first design deliverable needed before: Tyre can spec the verb computation, Mellanie can write trigger-catalog content, Ozzie can design the "First Day" tycoon experience, and Araminta can design the insert visual grammar. Everything downstream waits on this.

---

QUESTION FOR JEROEN 3: What does the CauseChain system track in a mission-less game?

The tension: Decision 15 (player choices ARE the content, Rimworld model) removes the formal mission system. Without mission objectives as trackable events, the CauseChain system has no obvious boundary for what constitutes a "choice worth tracking."

The concrete question: When the consequence engine remembers "this happened because of your decision," what categories of player decision are being tracked? Is it:

• Economic thresholds (you invested significantly in X, so when X is threatened it's your problem)
• Relationship events (you helped/harmed NPC Y, so Y now has a stance on you)
• World-state changes (you triggered action Z which changed district state, so Z's downstream effects are attributed to you)
• All of the above (and the storyteller filters for what's narratively interesting)

The consequence engine's performance and signal-noise ratio depends on how selective this tracking is. In Rimworld, the storyteller has access to all simulation state — it doesn't log "decisions," it just reads current state. If we're modeling consequences as stored cause chains, we need a policy for what gets recorded.

Why it matters: The answer determines whether CauseChain is a lightweight event log (high performance, potentially missing causes) or a comprehensive player history (richer consequences, more memory). For a Rimworld-model game without mission checkpoints, I'd lean toward reading current world state rather than logging past decisions — but that's a design hypothesis, not a decision.

---

Part 5: Reactions to Other Agents' Round 4

On Tyre's estimate revision

Tyre revised to 6-10 sprints and proposed the Tier A proof-of-life sprint before the full buildout. Decision 1 rejects Tier A. This doesn't invalidate Tyre's instinct — the concern about building too much before testing is correct. But the answer to that concern is: what does the first playable state look like within the generator-first approach? Not "skip the generator for a sprint." The generator needs to reach a "bare minimum playable" state earlier than its "production quality" state. That's the milestone to plan toward.

On Ozzie's "First Day" beat sheet

Ozzie's 7-beat first 30 minutes (character creation → alarm → appointment → insert activation → first work moment → first anomaly → first consequence seed) is the right structure for the tycoon bookmark. The tycoon's first work moment is probably: arriving at a business location, making your first economic decision (take the deal? inspect the asset? negotiate the terms?). The consequence seed is embedded in that first decision — a deal made today that will echo later. This is a design session that Ozzie, Paula, Mellanie, and I need to run together. I agree with Ozzie: one beat sheet, four domains.

On Mellanie's three monologue cadences

Mellanie correctly flags that the tycoon bookmark (Active + WFH + Gig in one career) produces three different monologue rhythms. For v0.2, I'd recommend designing the trigger catalog for the most common tycoon rhythm first (probably Gig — accepting deals is the episodic unit of tycoon play) and treating Active and WFH triggers as secondary content. The architecture should support all three; the first content pass can prioritize one.

On Gore's Phase 1 emotional register warning

"Don't let Phase 1 become the game's default emotional register." This is the most important design note in Round 4 from a systems standpoint. The Phase 1 quiet responsiveness (prices shift, NPCs remember) is the mechanism that prevents Phase 1 from feeling like a tech demo. Gore is right that if the player settles into "this world runs without me," Phase 2's authored pressure feels like an intrusion. The ambient responsiveness simulation features are the answer — not authored content, simulation behavior.

On Nigel's career-aware content distribution question

Nigel's Rimworld-model question (does the storyteller seed content career-aware, or does career determine the player's lens on universal content?) is elegant and I think the answer is: both, by design tier.

Phase 1: Content is distributed universally. The world has economic threads, social threads, institutional threads all running simultaneously. Career determines the player's lens on those threads — what's visible to them.

Phase 2: Authored pressure can be career-aware when it needs to be. A tycoon gets approached about the deal; a law enforcement player gets assigned the investigation of the same deal. Same authored ingredient, career-specific surface.

This is the right architecture because it doesn't require separate authored content per career — it requires career-filtered visibility on shared world content. That's cheaper to produce and more emergent in behavior.

On Miri's zone identity spec as NPC population spec

Miri correctly identifies the zone identity spec as the upstream dependency for the generator. I want to extend her point: the zone identity spec isn't just a worldbuilding document. It's also an NPC archetype distribution spec. For the generator to produce a working-class logistics zone, it needs to know: what archetype NPCs fill that zone, in what proportions, and what roles they fill. The FRIEND-figure assignment rule (which NPC in the tycoon's starting zone becomes their FRIEND) is part of this spec.

Miri's spec should have three sections: (1) visual/physical zone identity, (2) NPC archetype distribution per zone type, (3) economic behavior rules per zone type. This is a cross-domain document. I'd like to co-author it.

---

My Single Most Important Recommendation

Design the tycoon verb map and VerbPriorityProfile before any other v0.2 design work begins.

Every other domain is waiting on this:

• Tyre needs the verb taxonomy to spec the computation
• Mellanie needs the VerbPriorityProfile to write trigger-catalog content
• Araminta needs the tycoon verb prompt visual treatment
• Ozzie needs the tycoon tools to design the First Day
• Paula needs the tycoon FRIEND-figure context to spec Phase Zero
• I need it to confirm whether skills (Decision 5's "mostly C") need any gated exceptions in the economic verb space

The tycoon bookmark decision (Decision 4) resolved which bookmark. But "tycoon" is a concept, not a spec. A detective has "Investigate, Observe, Interrogate." A tycoon has... what? That question needs to be answered before Sprint 25 work planning, not during it.

This is the decision that costs a day to make and weeks to untangle if made wrong mid-implementation.

---

GESTALT — Round 5 complete. The 15 decisions are sound. The tycoon pivot is bold and right. The generator-first approach is ambitious and correct. The systems tensions I've flagged (culture/voice, Phase 1 responsiveness as simulation behavior, CauseChain scope without missions) are solvable — they just need explicit decisions. Get Jeroen's answers on the three questions above and I can finalize the tycoon VerbPriorityProfile spec within the same sprint.