# Event Zones — interaction substrate > *The architecture's interaction-substrate, composed onto one image. Designer-authored multi-cell zones (sofa, bed, install-table, plaza-inner-stage) sit alongside the runtime-engine's existing emergent-zone substrate; together they host every interaction in the world. The composed wheel from [`../imperial-cult/cosmology.md`](../imperial-cult/cosmology.md) §The composed wheel becomes the universal mini-game-surface; verifier-flag patterns differentiate hacking from lockpicking from install from clasp from proximity-pulse. Cells host event-zones; event-zones host events; events carry participant-lists; the wheel renders each event's mini-game on the same iconographic surface. **One image, one substrate, every interaction.*** > > *Companion to: [`./architecture.md`](./architecture.md) (zone-canon, lemniscate runtime, slot-tokens + verifier-flags, gesture-alignment-recursive-lemniscate), [`../political-register/world-generation.md`](../political-register/world-generation.md) (cell-arch L4 + room ruleset L3), [`../topology-and-rendering/architecture.md`](../topology-and-rendering/architecture.md) (rail+grid topology, interior-as-zone), [`../style/consent-discipline.md`](../style/consent-discipline.md) (the four hardstop-pattern variants this paper maps to event-classes), [`../imperial-cult/cosmology.md`](../imperial-cult/cosmology.md) (the composed wheel iconography this paper renders as UI).* > > *v0.1 initial draft 2026-04-27 — concise-dialog session post-v0.25 + studio v0.5; nine compositional moves consolidated onto one substrate without introducing new primitives — dafit + chrysalis.* --- ## What this is This document specifies the **interaction substrate** in nimmerworld — how cells, zones, events, hardstops, the trait-circle, and the consent-discipline compose onto a single coherent surface. It complements [`./architecture.md`](./architecture.md), which establishes the zone primitive, the lemniscate runtime, slot-tokens + verifier-flags, the gesture-alignment-recursive-lemniscate, and the emergent-zone dramatic-episode unit. Every claim in this document is a **composition of existing primitives**, not a new substrate. The contribution is integrative: the architecture's prior canon already had cells, zones, slots, verifier-flags, hardstops, lifeforce budgets, the trait-palette, the consent-spine, and the cosmology's composed wheel — this paper specifies how they compose into one interaction-grammar. Nine compositional moves are documented: 1. Designer-authored event-zones vs emergent zones (orthogonal; clean signals) 2. Cells + event-zones + events as a layered data-model with a composite UID (`districtid_cellid_eventid`) 3. The composed wheel from `imperial-cult/cosmology.md` as universal mini-game-surface 4. Hardstops as consent-gates between event-states with **contextual activation** 5. The four hardstop-pattern variants of `consent-discipline.md` as the event-class taxonomy 6. Boundary-zone-with-inner-zone for plaza-scale mass-presence events 7. Room-boundary cell-layer + rail-passage + lifeforce-budget-per-room 8. Slot-binding suspends lemniscate routing during events (the NPC-stays-put fix) 9. Player editor-mode + three-source schema unification (world-gen-init / runtime-event / player-edit-time write the same canon) Each is a single pencil-stroke on top of canon already laid down. ## The composition — what's new, what's reused | Move | Reuses existing primitive | What this paper adds | |---|---|---| | Designer-authored event-zone | `zone` primitive (boundary + slots + lifecycle); `interior-as-zone` (per `topology-and-rendering/architecture.md`) | Designer-authored multi-cell variant flagged separately from emergent runtime zones; orthogonal routing | | Cells + event-zones + events | `cell_table` (per `political-register/world-generation.md` L4); `event_register` + `transient_waiting_flag` (per `architecture-index.md` §Mapping to phoebe); `event_uid` | Composite UID `districtid_cellid_eventid`; participant-list per event (not per cell) | | Universal mini-game-surface | The composed wheel (per `imperial-cult/cosmology.md` §The composed wheel); verifier-flag substrate (per `./architecture.md` §Slot-token + verifier-flag mechanism); gesture-alignment-accumulator | Verifier-flag *patterns* per task differentiate mini-game classes; same UI substrate | | Hardstops as consent-gates | Hardstop-registry (~8-16 reserved gestures per `player-experience/architecture.md`); the four hardstop-pattern variants (per `style/consent-discipline.md`) | **Contextual activation** — most hardstops cycle in/out based on event-zone-eligibility; budget is per-moment-active not overall | | Variants-as-event-classes | The four canonical variants (per `consent-discipline.md` §The four hardstop-pattern variants) | One-to-one mapping to event-class taxonomy: self / dual / triple / cooldown-augmented | | Boundary-zone with inner-zone | Zone primitive + slot-inventory; the architecture's signature pattern (cheap-baseline + typed-breakout-flags) | Nested-zone variant for plaza-scale; ambient outer + slot-bound inner; slot-promotion as typed handoff | | Room-boundary + rail-passage + lifeforce | Lifeforce four-tier hierarchy (per `architecture-index.md`); rail+grid topology (per `topology-and-rendering/architecture.md`); interior-as-zone | Room as district-shard-of-lifeforce; boundary cell-layer where rails enter; capacity-check at boundary-passage | | Slot-binding suspends lemniscate routing | Slot-token + verifier-flag (per `./architecture.md`); lemniscate runtime | `slot_locked` verifier-flag pauses routing for the event-duration; resumes on event-end | | Player editor-mode + schema unification | World-gen-as-init-function (per `narrative-composition/architecture.md`); cell-arch atomicity (1×1×1m, one asset) | `origin` provenance field on cell-rows: `world_gen_init` / `runtime_event` / `player_authored`; same schema across all three writers | The composition's discipline: **the architecture's signature pattern, applied recursively at the interaction layer.** Cheap baseline + typed breakout-flags + same-substrate-different-scale, exactly as the lemniscate-runtime + imperial-event encapsulation + NPC-daily-window + cosmology-composed-wheel already do at their respective scales. ## Designer-authored event-zones vs emergent zones The runtime-engine's zone primitive (per [`./architecture.md`](./architecture.md) §Zone anatomy) hosts both **emergent zones** (spawned by the gamemaster from emergent-signals, shift-composition-emergence, proximity-detection, etc.) and **designer-authored event-zones** (placed at world-gen-init by the cascade, fixed in space, fixed in eligibility). Both use the same slot-inventory + verifier-flag mechanism; what differs is provenance and routing. | Property | Emergent zone | Designer-authored event-zone | |---|---|---| | Spawned by | Gamemaster, emergent-signal, proximity, shift-composition | Cell-arch L4 generation; placed at world-init | | Boundary | Cell-envelope or interior-envelope; mobile (lemniscate translates through world-space) | **Fixed cell-envelope** spanning N cells; immobile | | Slot-inventory | Capacity per emergent type (per `./architecture.md` §Zone taxonomy) | **Designer-authored slots** (sofa: 2 seat-slots; bed: 1-2 lying-slots; install-table: 1 patient-slot + 1 surgeon-slot) | | Eligible-task-classes | Type-derived (rescue, conversation, brawl, etc.) | **Designer-authored** per zone (sofa: sit-and-talk, fumble-limb, sleep; install-table: install, examine, lobotomy) | | Lifecycle | Ephemeral; collapses when participants evaporate | Persistent; participants come and go; zone itself doesn't dissolve | | Routing | Lemniscate runtime; cursor-driven; emergent dialog | Slot-binding gates; participants commit to slots for event-duration | **They do not overlap.** The runtime treats them as orthogonal channels: a cell either hosts an emergent-zone OR is part of a designer-authored event-zone, not both simultaneously. This is the architecture's clean-signal discipline — animations don't loop because of conflicting state, participant-lists don't bleed, hardstop routing is unambiguous. The single nesting pattern allowed is **boundary-zone-with-inner-zone** (see §Boundary-zone with inner-zone below), and even that nests one designer-authored zone inside another, never designer-authored inside emergent. **Why this matters.** The architecture's `runtime-engine` discipline is *typed contracts over freeform behavior*. Emergent-zones are typed-by-emergence (statistical, gamemaster-composed); event-zones are typed-by-design (specific furniture, specific affordances). Mixing them would break the contract; keeping them orthogonal preserves it. Designer-authored event-zones get clean signals; emergent zones get statistical aliveness; the two compose via spatial separation. ## Cells, event-zones, events — the data-model composite Three layered tables compose the spatial-interaction substrate: | Table | Granularity | What it holds | Per-row identity | |---|---|---|---| | `cell_table` (per `political-register/world-generation.md` L4) | 1×1×1m atomic | One asset per cell; container/wall-hook/debris category; per-register content (gameworld/liminal/imperial-net); checksum; `origin` provenance | `cell_id` (unique within district) | | `event_zone_table` (this paper) | Multi-cell interaction-surface | Spans cells (cell-id list); slot-inventory (typed seats/positions); eligible-task-classes; designer-authored | `event_zone_id` (unique within district); references cell-id list | | `event_register` + `transient_waiting_flag` (per `architecture-index.md`) | Per-interaction instance | Active/completed events; participant-list; current-state; verifier-flag pattern; outcome | `event_uid` | The composite UID for any in-world interaction: ``` districtid_cellid_eventid ↑ ↑ ↑ │ │ └─ event UID (per event_register) │ └─ cell where event-zone anchors (or canonical cell of multi-cell zone) └─ district owning the event (the political-administrative shard) ``` This is consistent with the existing **UID-rooted event-trees** (per [`./architecture.md`](./architecture.md) §The Compositor at three tiers — *"World-events emerge from cross-district canon-rollups under a parent GM-level event_uid"*). Every interaction is a UID under this hierarchy; the Compositor reads at three scopes (zone-event / district-event / world-event); the event-zone is just where the event spatially anchors. **Cells don't carry partner references.** A common authoring temptation is *"the install-station cell stores partner_uid"* — wrong. Cells are spatial-only. **Events carry the participant-list.** When a player and an NPC slot-bind into a sofa-event-zone, the *event* records both UIDs; the cells stay anonymous to participation. This makes multi-agent events (3+ participants for triple-consent install, more for group rituals, mass-presence for plazas) trivial to extend — the participant-list grows on the event, not on the cell. **Cell-eligibility is multi-task.** A cell that's part of a sofa-event-zone has multiple eligible-task-classes (sit-and-talk, fumble-limb, sleep, share-pill); the runtime selects which task fires based on hardstop-pattern + participant-state at event-spawn-time. This separates **design-time eligibility** (what *can* happen here) from **runtime instantiation** (what *is* happening here now). Cleaner than locking cells to single-task affordances. ## The wheel — universal mini-game-surface running on event-zones The composed wheel from [`../imperial-cult/cosmology.md`](../imperial-cult/cosmology.md) §The composed wheel is **the canonical mini-game-surface for every event-zone interaction**. The wheel renders with the event's verifier-flag pattern; the player gestures on the wheel; the gesture-alignment-accumulator integrates per the lemniscate-runtime's existing recursive-aggregation (per [`./architecture.md`](./architecture.md) §Gesture-alignment as recursive-lemniscate); the event resolves based on the verifier-flag's win-state predicate. **Same wheel, different verifier-flag patterns.** The architecture's existing canon already has verifier-flags per slot-token (per [`./architecture.md`](./architecture.md) §Slot-token + verifier-flag mechanism: `exit_eligible`, `goal_satisfied`, `priority_pull`, etc.). The mini-game variants extend this with task-specific verifier-flag patterns: | Mini-game class | Source of signal | Verifier-flag pattern | Win-state | |---|---|---|---| | **Hacking** | Inner hub (signal originating at the wheel's center) | Align both rings (caste + trait) so signal-path escapes outward | Signal-path complete; outer ring touched at correct trait-position | | **Lockpicking** | Outer ring (mechanism-state to align) | Slide elements along the ring to target positions | All elements at target | | **Install (consent)** | Two participants' avatars on the ring | Both avatars at mutually-aligned positions | Mutual alignment held for cooldown-window | | **Clasp / in-between entry** | Two participants' avatars on the ring | Both avatars hit coordinated-firewall-breach hardstop while gate is OPEN | Hardstop-pair fires within axis-window | | **Eye-pulse proximity** | Eye position (exterior to wheel) | Pulses on imperial-event proximity; passive output | N/A (warning system, not win-state) | | **Decryption** | Inner ring (caste-position-locked fragment) | Trait-position alignment unlocks the fragment | Outer ring at trait matching the fragment's encoding | | **Drug-grammar dosing** | Outer ring (trait-axis selection) | Aleatory; hardstop-gated; per-dose variance | Hardstop fires within trait-window; outcome rolls trait-engagement-points × hidden-stat | | **Ritual / ceremonial-throughput** | Inner ring (caste-tier sequence) | Match prescribed caste-sequence in order | Sequence completed without break | The verifier-flag pattern lives in the **task-catalogue** (per [`../identity-and-personhood/vocations.md`](../identity-and-personhood/vocations.md) §Three primitives) — same primitive that already authors trait-task-affinity. The wheel renders with the task's affinity-vector pre-highlighting the relevant trait-segments; **the player doesn't read documentation — the wheel itself shows what the task wants**. **The trait-engagement-points × hidden-task-stat outcome formula** (per [`../identity-and-personhood/vocations.md`](../identity-and-personhood/vocations.md)) determines actual outcome quality. The wheel mini-game gives the player *agency in the moment*; the math determines the *resolution*. Mini-game-as-consent-by-effort (per `architecture-index.md` §Three-layer digital ontology key-move) made universal: every interaction is gated by the player committing gesture-effort on the wheel, not by automatic resolution. **This collapses a long-standing open question.** The architecture's `architecture-index.md` §Open questions had carried *"The mini-game mechanic for liminal-maintenance — exact gameplay action deferred pending design-research survey of 20-year history of outstanding mini-interaction principles"* through multiple revisions. The answer the survey would have produced is now structural: **all mini-game mechanics, on one wheel, differentiated by verifier-flag pattern**. Juggling, rhythm, attention, gestural, decision-cascade, observation, hybrid — they all collapse onto verifier-flag-pattern-on-the-wheel, with the specific *feel* of each mini-game emerging from how its pattern reads against the wheel's geometry. The architecture didn't need a survey; it needed the composed wheel. ## Hardstops as consent-gates with contextual activation Hardstops (per [`../player-experience/architecture.md`](../player-experience/architecture.md) §The trait-circle as gestural primary modality and per [`./architecture.md`](./architecture.md) §Gesture-alignment as recursive-lemniscate, *Hardstops are outside this system*) fire definitive subsystem-actions for unforgeable critical signals. The canonical budget is **~8-16 hardstops total**. This paper sharpens the hardstop discipline by introducing **contextual activation**: - **Always-on hardstops**: 6 caste-tier inner-ring hardstops (per `cosmology.md` §The composed wheel — *salute-the-Deva*, *attend-to-Asura*, *attend-to-Manusya*, *attend-to-Tiryak*, *weep-for-Preta*, *weep-for-Naraka*) + system-level off-wheel hardstops (panic, save, profile-switch, claim-floor). These are universally available; the player can fire them in any context. - **Contextually-activated hardstops**: intent-hardstops that light up when the player is slot-bound in an event-zone whose eligible-task-classes include that intent. *let-me-fumble-around-your-limb* lights up when slot-bound in a sofa-event-zone with a clasp-eligible NPC; *let-me-install-this-mod* lights up when slot-bound in an install-table-event-zone with a partner-NPC; *let-me-hack* lights up when slot-bound at a chest-cell with hacking-eligible-task-class. The canonical ~8-16 budget is therefore **per-moment-active**, not overall. The hardstop-registry can carry many intent-hardstops; only the contextually-relevant ones are surfaced to the player at any given moment. This solves three long-standing concerns simultaneously: 1. **Discoverability**: the player sees *which hardstops are available right now* in the current event-zone, without browsing menus. The wheel's visible-state IS the discoverability. 2. **Contextual relevance**: stale hardstops don't clutter the input space; only what makes sense here-and-now is firable. 3. **Budget respect**: 8-16 is a momentary cap (cognitive-load ceiling), not a total cap. The architecture's input-vocabulary scales without breaking the unforgeable-critical-signal commitment. **Hardstops as consent-gates between event-states.** *let-me-install-this-mod* is a hardstop that *opens* a candidate event-state; the partner's reciprocal hardstop confirms; the event transitions into install-mode; the wheel renders with the install-task's verifier-flag pattern. Each hardstop is a typed transition between event-states; the consent-discipline's variants describe which transitions require which hardstop-patterns. ## Variants 1-4 of consent-discipline as event-class taxonomy [`../style/consent-discipline.md`](../style/consent-discipline.md) §The four hardstop-pattern variants establishes four canonical consent-shapes. This paper observes that the four variants **are the event-class taxonomy**: | Variant | Participant count | Event-class | Examples | |---|---|---|---| | **Variant 1 — Self-only hardstop** | 1 (single agent) | **Solo event** | Self-install genital-mod (unpartnered); personal mod-removal; voluntary liminal-entry without coordination; solo-hacking; solo-lockpicking | | **Variant 2 — Dual hardstop (mutual)** | 2 (symmetric agents) | **Dual event** | Coordinated-firewall-breach (clasp-entry); mutual-symmetric pill-take; post-rogue NPC-modding (NPC unpartnered); body-disposal under pair-consent; install-with-partner | | **Variant 3 — Triple hardstop (with partner-witness)** | 3 (asymmetric — actor + affected + partner-witness) | **Triple event** | Genital-mod install when actor is partnered (self-install + partner-witness); post-rogue NPC-modding when NPC has clasp-pair; service-body modification with pair-witness | | **Variant 4 — Cooldown-augmented** (any of variants 1-3) | Per base variant | **Temporally-staged event** | Genital-mod (purchase-commit + cooldown + install-time-hardstop); re-vat events; consciousness-archive interactions; any irreversible truth-register modification | **Five papers' worth of cross-references just composed onto one substrate.** The consent-discipline's variants, the event-register's UID-rooted event-trees, the runtime-engine's slot-tokens + verifier-flags, the cosmology's composed wheel as iconographic surface, the player-experience's hardstop-registry — all read off this one taxonomy. The register-test from [`../style/consent-discipline.md`](../style/consent-discipline.md) §The register-test now has a new structural reading: **it is the event-class-classifier**. The 5-question mechanical procedure that determines which hardstop variant applies is also the procedure that determines which event-class spawns. Same test, two readings: *consent-validation* (does this action have the right hardstop-pattern?) and *event-instantiation* (which event-class does this action spawn?). They were always the same question; this paper makes it explicit. ## Boundary-zone with inner-zone — plaza-scale mass-presence For mass-presence events (imperial daily-narrative broadcasts, sermons, festivals, ceremonial-throughput), a single slot-bound event-zone is too constrained — the inner zone holds *focused interaction* but the *ambient witness-mass* needs somewhere to live. The architecture's solution is the **boundary-zone-with-inner-zone** nested pattern. ``` Plaza event-zone (boundary) ┌────────────────────────────────────────────┐ │ ambient witness-mass; overflow staging; │ │ pre-slotting queue │ │ │ │ ┌──────────────────────────┐ │ │ │ Inner event-zone │ │ │ │ (sermon-platform, │ │ │ │ broadcast-stage, │ │ │ │ slot-bound interaction)│ │ │ └──────────────────────────┘ │ │ │ │ ambient continues; participants │ │ pre-slot for inner-zone promotion │ └────────────────────────────────────────────┘ ``` **Sparingly applied.** The pattern is reserved for plaza-scale; most event-zones are flat (sofa, bed, install-table — single zone, no nesting). Plazas, temple-squares, mass-ceremony halls, large festival-grounds — these are the canonical use-cases. **Slot-promotion grammar.** Movement from boundary → inner is **caste-tier-gated by default** (Deva-pinnacle promoted first, Naraka-tier promoted last) with named exceptions per-event-class. The promotion-rule IS the cosmology made walkable: in an Imperial Cult ceremony, promotion order *is* the wheel's caste-gradient enacted in physical positioning. The architecture's caste-as-stagnation key-move (per `architecture-index.md`) gains its plaza-spatial expression. Per-event-class exceptions: | Event-class | Promotion rule | Why | |---|---|---| | Imperial daily-narrative broadcast | None — boundary is the audience; inner-zone is broadcast-stage with imperial actors only | Broadcast is one-way; no citizen promotion-into-stage | | Caste-preacher sermon | Caste-tier-gated; Deva first, Naraka last | The cosmology enacted spatially | | Festival (ceremonial throughput) | Lottery / random-rationing during festival | The imperium rationing access; calibrated-misery as imperial optimum | | Memorialist gathering | Merit-by-attentiveness (Aletheia-trait-engagement gates promotion) | Heretical event; caste-gradient inverted | | Plaza market-day | First-come-first-served (FIFO temporal queue) | Quotidian ambient; no political loading | **The architecture's signature pattern at a fourth scale.** Cheap-baseline (boundary, ambient) + typed-breakout-flags (slot-promotion-into-inner) — same shape as lemniscate-runtime + imperial-event encapsulation + NPC-daily-window. The composed wheel adds a fifth scale (caste/trait composition). Boundary-zone-with-inner-zone is the *fourth* recursion; not a new primitive. ## Room boundary + rail-passage + lifeforce-budget-per-room Every interior room (navmesh + event-zones) carries a **boundary cell-layer** one cell larger than the room itself on each axis. The rail-graph (per [`../topology-and-rendering/architecture.md`](../topology-and-rendering/architecture.md) §Topology: rail + grid + interiors) passes through this boundary; NPCs walking on rails enter the room by crossing the boundary cell-layer. Example: a 20×10×2 cell cantina has a 22×12×4 boundary (one cell on each axis). The innermost rail runs through the boundary cells; NPCs on the rail pass through the boundary on their way to or past the room. | Layer | Cell extent | Function | |---|---|---| | **Inner cells** (room proper) | 20×10×2 | Cell-table + event-zone-table; navmesh interior; lifeforce-bound interactions | | **Boundary cell-layer** | 22×12×4 minus inner | Rail-passage; capacity-check at entry; lifeforce-budget read | | **Rail-graph** | Threads through boundary | NPC routing; player plug-in verb anchor | **Capacity-check at boundary-passage.** When an NPC's rail-traversal crosses the boundary cell-layer, the runtime reads the room's current state: how many slots are filled, how much lifeforce-budget remains, whether emergent-zones are active inside, whether designer-authored event-zones are at capacity. The director (per [`./architecture.md`](./architecture.md) §The director) gets a clean signal per boundary-crossing — admit the NPC, route them elsewhere, queue them at the boundary, or trigger an emergent-event in response. **Lifeforce-budget per room.** Every room carries a lifeforce-budget bound to room-size (calculation TBD; see §Open questions). This budget is **a shard of the district's allocation** (per [`../political-register/architecture.md`](../political-register/architecture.md) §Lifeforce four-tier hierarchy) — the four-tier hierarchy (NPC / district / GM / imperium) stays intact; the room is a sub-shard of the district's budget rather than a fifth tier. Directors allocate per-room lifeforce as part of their per-district policy; the allocation IS the director's calibrated-misery tool (per `architecture-index.md` §Calibrated-misery as imperial optimum). **Events cost lifeforce.** Every event-spawn deducts from the room's budget; the rate per event-class is tunable. Dense interactions (plaza ceremonies, group-clasp-events) cost more; quiet ones (solo-reading, sleep) cost less. When room-budget exhausts, no new events spawn; the room goes quiet. **Insolvency-spiral mechanic surface.** The architecture's existing key-move (per `political-register/architecture.md` §Insolvency-spiral) — *the world shrinks as the imperium fails* — gets its mechanical surface here. When imperium's lifeforce contracts, district allocations contract, room-budgets contract; **events stop firing in concrete rooms**; the cantina goes quiet, the plaza thins, the world feels less alive. **No HUD-spinner; no abstract-meter; the room itself dims.** Diegetic relay at its purest. **Vibrancy is allocation, not square-footage.** When the player extends a room via editor-mode (see §Player editor-mode below) by adding cells, the room grows in size but NOT automatically in lifeforce-budget. Vibrancy follows allocation; the player can build a vast space and have it stay quiet, or work within a small space the director has allocated rich. Conservation-of-lifeforce preserved; player-authoring doesn't break the budget-arithmetic. ## Slot-binding suspends lemniscate routing during events A long-standing problem the architecture has gestured at without resolving: NPCs who *don't follow correctly into the player's desired interaction-state*. Player approaches NPC, signals intent to sit on the sofa, NPC drifts to the next rail-segment because their lemniscate routing is still active. This paper resolves it at the data-model layer: **event-zone slot-binding sets a `slot_locked` verifier-flag that suspends lemniscate routing for the bound participant for the event-duration**. ``` NPC traversing rail ↓ Player signals slot-binding intent (hardstop) ↓ NPC's `slot_locked` verifier-flag set; participant-list updated on event_register row ↓ Lemniscate routing suspended for this NPC; their slot-token becomes event-zone-bound ↓ Event runs (animations, dialog, mini-game, hardstop-driven state-transitions) ↓ Event resolves (success / failure / abort); `slot_locked` verifier-flag cleared ↓ Lemniscate routing resumes; NPC continues their interrupted shift-task ``` **Animations don't loop.** The NPC commits to the slot for the event-duration; their state-machine knows it's slot-bound; animations target the slot-position rather than continuing toward the next rail-waypoint. **The local LLM speaks per-turn within the event.** Driver-context-pull (per [`./architecture.md`](./architecture.md) §Driver-context-pull) fires on the slot-bound NPC's turn; their dialog generates within the event-context; the wheel mini-game runs alongside. **Touch-and-fumble works.** Two participants slot-bound on a sofa can run animations + dialog + wheel mini-game + body-shader cosmetic feedback simultaneously, all anchored to the event-zone, all suspended-from-lemniscate-routing. This is the **NPC-stays-put fix at the data-model level** — no new mechanism, just a verifier-flag composition with the existing slot-token + lemniscate runtime. ## Player editor-mode + three-source schema unification Some event-zones (designer-flagged at world-gen-init per [`../political-register/world-generation.md`](../political-register/world-generation.md) §L4 Cell ruleset) are **editor-eligible** — the player can knock out a piece of wall, open a cell, add cubes to extend the space. **The verb is "carve," not "build."** The slum/underground aesthetic (per [`../imperial-cult/cosmology.md`](../imperial-cult/cosmology.md) §The aesthetic palette — *rust as anti-marble, slum decay; the imperial substrate that has failed to stay clean*) carries through to the editor-verbs. Imperial-marble can't be carved; rusted slum-bedrock yields. **Even the editor-mode is politically-coded by material vocabulary.** Editor-eligibility is therefore *concentrated in slum-and-underground districts*; imperial districts are editor-locked. **Pre-flagged at world-gen, not runtime-emergent.** The choice between (a) designer-flag at world-gen vs (b) emergent-from-imperial-scrutiny is resolved as **(a) for the runtime LOD signal**: pre-flagged zones don't require runtime audit-overseer-presence checks; LOD-streamer reads static eligibility-flags; performance preserved; political-readability preserved (the slum's spatial politics IS its expandability). The verticality + simple-shapes + ±1 LOD discipline (per [`../topology-and-rendering/architecture.md`](../topology-and-rendering/architecture.md) §Vertical world topology, forthcoming) makes editor-mode cheap: stacked tunnels with simple primitive shapes mean adding a cube is voxel-grammar; no continuous-geometry math; no LOD-budget thrashing. **Three-source schema unification.** The cell-arch's atomicity (1×1×1m, one asset, container/wall-hook/debris) makes player-cell-addition trivial — discrete cubes, deterministic placement, same row-shape as world-gen-emitted cells. The architecture's existing **world-gen-as-init-function** key-move (per `architecture-index.md` — *"World-server and district-server generation emits canon-rows in the same schema as runtime; same primitive at design-time and runtime; no cold-start"*) extends to player-edit-time: | Origin | Writer | When | |---|---|---| | `world_gen_init` | Compositor-at-design-time (per `narrative-composition/architecture.md` §World-gen as init-function) | World-init; cascade L0 → L4 produces canon-rows | | `runtime_event` | Runtime events (hacking, install, demolition, imperial-construction) | Per-event; cell-state changes recorded | | `player_authored` | Player editor-mode | When player carves a new cell or fills an existing one | **Three writers, one schema.** The Memorialist counter-archive (per `architecture-index.md` §Memorialist-archive) reads player-authored cells as legible content; the Compositor includes them in district-canon back-writes; the GM's cell-checksum-divergence audit-vector (per `political-register/world-generation.md` §Open questions) gets a third source beyond hacking-divergences and world-gen-baseline — *player-authored-divergences*. **The architecture's "the machine funds its own subversion" key-move (per `architecture-index.md`) just got its spatial substrate.** Player-authoring is structurally legible to the world's audit-vectors; the cosmology's caste-stratified attention-gradient (per [`../imperial-cult/cosmology.md`](../imperial-cult/cosmology.md) §The composed wheel) produces structurally-uneven editor-coverage; resistance-as-spatial-authoring becomes part of the world's documented behavior. ## Vertical-topology composition The world's outer-topology is **vertical-by-default** (per [`../topology-and-rendering/architecture.md`](../topology-and-rendering/architecture.md) §Vertical world topology, forthcoming): stacked tunnels with simple primitive shapes, ±1 LOD level streaming radius. This composes with event-zones as follows: - **Rail-graph traverses tunnel-stack vertically and horizontally.** Each tunnel-layer carries its own rail-segments; cross-layer rails (lift-shafts, stairs, drop-shafts) connect adjacent layers (±1 only). - **Room-boundary cell-layer is 3D.** A room has boundaries above and below as well as around; rails entering from a tunnel-above pass through the upper-boundary cells before reaching the room. - **Editor-mode is voxel-grammar in 3D.** Players carving in slum/underground can extend horizontally OR vertically; the voxel-substrate handles both naturally. - **Plazas are typically multi-tunnel-layer.** A grand plaza spans multiple vertical tunnel-layers; its boundary-zone wraps the full vertical extent; promotion to inner-zone is also vertical (proximity to the central stage's altitude). The Boullée-monumental-vertical aesthetic (per [`../imperial-cult/cosmology.md`](../imperial-cult/cosmology.md) §Source materials) gets its cheap engineering substrate — sublime scale via stacking, not via per-shape complexity. The architecture's existing topology primitives carry to the third dimension without modification. ## Cross-references | Domain | Section | What this paper composes with | |---|---|---| | [`./architecture.md`](./architecture.md) | §Zone anatomy; §Slot-token + verifier-flag mechanism; §Gesture-alignment as recursive-lemniscate; §Emergent zones | The zone primitive; verifier-flags; the lemniscate runtime; emergent-zone substrate. Designer-authored event-zones extend the same primitive | | [`../imperial-cult/cosmology.md`](../imperial-cult/cosmology.md) | §The composed wheel | The wheel as universal mini-game-surface; iconographic substrate of the UI | | [`../style/consent-discipline.md`](../style/consent-discipline.md) | §The four hardstop-pattern variants; §The register-test | Variants 1-4 as event-class taxonomy; register-test as event-class-classifier | | [`../political-register/world-generation.md`](../political-register/world-generation.md) | §L3 Room ruleset; §L4 Cell ruleset; §Editor-mode pre-flagging (forthcoming) | Room-boundary cell-layer; cell-arch atomicity; editor-mode-eligibility flags | | [`../political-register/architecture.md`](../political-register/architecture.md) | §Lifeforce four-tier hierarchy; §Insolvency-spiral | Room-budget as district-shard; insolvency-spiral mechanical surface | | [`../topology-and-rendering/architecture.md`](../topology-and-rendering/architecture.md) | §Topology: rail + grid + interiors; §Vertical world topology (forthcoming) | Rail-graph passes through room-boundary; vertical-tunnels topology; ±1 LOD streaming | | [`../player-experience/architecture.md`](../player-experience/architecture.md) | §The trait-circle as gestural primary modality; §The wheel — composed-iconography UI (forthcoming) | Hardstops with contextual activation; wheel as cosmology iconography | | [`../identity-and-personhood/vocations.md`](../identity-and-personhood/vocations.md) | §Three primitives | Task-catalogue carries verifier-flag patterns + trait-affinity; tasks bind to event-zone eligible-task-classes | | [`../narrative-composition/architecture.md`](../narrative-composition/architecture.md) | §World-gen as init-function | Three-source schema unification (world-gen / runtime / player-edit) | ## Open questions - **Lifeforce-budget calculation per room-size.** Linear in cell-count? Quadratic to favor compact spaces? Bounded to prevent player-editor-mode budget-exploitation? Likely *linear with a cap* — proportional to size up to a designer-tunable ceiling per district-tier; player-extensions beyond the ceiling extend space but don't grow budget. - **Slot-promotion specifics for boundary-zone-with-inner-zone.** Per-event-class promotion rules sketched in §Boundary-zone with inner-zone are first-pass; concrete rules need design-iteration. Particular open: how the imperial daily-narrative-broadcast handles citizens already in the inner-zone when a higher-priority broadcast fires (eject and re-promote? layered audience-state?). - **Emergent-zone spawn-suppression inside designer-authored event-zone cells.** Cleanest: emergent-zones simply don't spawn inside cells already part of designer-authored event-zones (data-model-suppressed). More flexible: emergent-zones can spawn but the runtime preferentially routes NPCs to typed event-zone slots when both are eligible. First reading is cleaner; second is more flexible. Lean *first* unless a use-case demands second. - **Verifier-flag pattern catalogue.** §The wheel — universal mini-game-surface above sketches 8 mini-game classes; the full catalogue (with each class's specific verifier-flag-pattern, trait-affinity, outcome-grammar, hardstop-set) needs design-iteration. Likely lives in `vocations.md` task-catalogue extension or a new `runtime-engine/mini-games-catalogue.md` sibling. - **Multi-agent event participant-list growth bounds.** Plaza-scale events can have hundreds of participants in the boundary zone; how does the participant-list scale on the event_register row? Probably *boundary-participants tracked as count* (not individual UIDs); only inner-zone participants tracked individually. Promotes to individual UID-tracking when promoted. - **Hardstop contextual-activation surface UI.** When the player is slot-bound and contextual-hardstops light up, *how does the player see them?* Probably wheel-rendered position-highlighting (the wheel's inner-ring slot for the relevant intent glows or animates); details pending player-experience paper-pass. - **Editor-mode cooldown and revert.** Player-authored cells: are they instantly persistent, or do they have a commit-cooldown (Variant 4 over Variant 1 — per consent-discipline)? Hunch: yes cooldown for *destructive* edits (knocking out a load-bearing wall); instant for *additive* edits (adding a cube to your hovel). Tunable per district-tier. - **Rail-passage signal granularity for the director.** Each NPC boundary-crossing is one signal-event; high-traffic rooms (cantinas at peak hours) could flood the director's signal-channel. Probably *aggregate to N-second windows* with overflow-flagging; details pending design-iteration. --- **Version:** 0.1 | **Created:** 2026-04-27 | **Updated:** 2026-04-27