# MMO Instancing Architecture Design

## Status

Current repository artifact for IARPG-OPS-2 2.0.13-wip. Claim-review status: **reviewed with limitations**. The preserved source body remains unchanged as provenance, while the `Reviewed Synthesis` section records the current publication decision. Only that reviewed synthesis may be reused as current factual or design guidance; archival source prose remains non-authoritative unless a claim is explicitly dispositioned below.

## Purpose

Preserve the supplied research as a canonical durable report, make it individually addressable under `/docs/long-term-memory/reports/`, and connect its current design implications to compact `.uai` startup memory without duplicating the full body in hot memory.

## Scope

This report covers the research and design questions contained in `MMO Instancing Architecture Design.md`. It is authoritative for repository provenance, routing, and preservation. It is not automatically authoritative for current law, clinical guidance, platform policy, market facts, technical capability, or production implementation.

## Executive Summary

This report is retained as a menu of MMO instancing patterns. It does not establish a production architecture, capacity result, or clinical simulation claim. The review applies claim-by-claim dispositions for current law, public institutions, clinical and rights guidance, age and consent, products, vendors, market assertions, software capabilities, design parameters, and comparative fairness. Unsupported or time-sensitive source statements are corrected, bounded, omitted, or retained only as design hypotheses.

## Evidence Reviewed

- [Preserved source file](../../source-files/saudi-intelligence-security-apparatus/MMO%20Instancing%20Architecture%20Design.md)
- Source collection: `saudi-intelligence-security-apparatus-archive`
- Source SHA-256: `0a7712ac7b3fbc49185869f3bf7f622727c499902e6df33c6698292352875759`
- [Claim-review register](../../standards/claim-review-register.json)
- [Claim-level review and comparative fairness audit](claim-level-review-and-comparative-fairness-audit.md#findings)
- [WHO/OHCHR — Mental health, human rights and legislation](https://www.who.int/publications/i/item/9789240080737)
- [OWASP — Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/)
- [Complete source-to-report map](../research/source-to-report-map.md#source-to-report-map)
- [Provided-report intake audit](../research/provided-report-intake-audit.md#current-94-file-archive-intake)

## Reviewed Synthesis

### Publication Decision

Retain this report as the canonical repository copy of `MMO Instancing Architecture Design.md`. The source body below remains preserved for provenance and research history, but its factual assertions do not steer current product or public claims unless they appear in this reviewed section. Review completed for 2.0.13-wip; re-check date-sensitive items before later publication.

### Claim Dispositions

| Claim ID | Topic | Disposition | Current bounded statement | Review evidence |
|---|---|---|---|---|
| `CR-OPS2-213-6FF7D97C-01` | architecture | **design-hypothesis** | Treat shard size, persistence, replication, queueing, and handoff patterns as architecture options until load-tested against a defined engine, traffic model, failure budget, and privacy boundary. | Repository review; no external claim retained |
| `CR-OPS2-213-6FF7D97C-02` | performance | **not-established** | No current production MMO host or engine exists in this repository. Numeric capacity and latency values are test targets only. | Repository review; no external claim retained |
| `CR-OPS2-213-6FF7D97C-03` | hospital setting | **rejected** | Instancing is a game-systems decision and cannot validate clinical, legal, or ethical claims about real hospitals. | [WHO/OHCHR — Mental health, human rights and legislation](https://www.who.int/publications/i/item/9789240080737) |
| `CR-OPS2-213-6FF7D97C-04` | privacy | **corrected** | Isolation must be enforced and tested at identity, authorization, data, logging, spectator, moderation, and cross-instance state boundaries. | [OWASP — Application Security Verification Standard](https://owasp.org/www-project-application-security-verification-standard/) |
| `CR-OPS2-213-6FF7D97C-05` | fairness | **corrected** | Plan for latency, language, moderation capacity, accessibility, data residency, and degraded connectivity across regions without assigning lower-quality play to particular countries. | Repository review; no external claim retained |

### Comparative Fairness and Rights Boundary

Regional infrastructure planning must avoid a single-market default and must consider language, accessibility, connectivity, moderation, latency, data governance, and equitable service quality.

### Reuse Rule

Use the smallest applicable corrected statement above, preserve its jurisdiction and date boundary, and cite the listed primary or authoritative source. Do not quote the archival source body as current fact without a new claim review.

## Findings

> **Archival source boundary:** The material below is preserved source-derived analysis. It may contain stale, unsupported, stigmatizing, culturally narrow, overly actionable, or product-specific claims. The `Reviewed Synthesis` above—not the archival prose below—is the current repository publication decision.

### Preserved Source-Derived Analysis

### **Rogue Intelligence: Hospital Instancing and Multiplayer Architecture Specification**

#### **1\. Hospital Instancing Specification**

In the context of the Rogue Intelligence Minimum Viable Product, a hospital instance operates as a transient, server-authoritative simulation bounding the physical and logical realities of the game world1. Unlike traditional monolithic server architectures, this instancing framework utilizes horizontally scaled, containerized processes to manage discrete pockets of the player base, ensuring that the strict limitation of ten human players per environment is never violated2. The architecture strictly decouples the concept of an instance from the underlying persistence layers, treating the instance merely as a computational arena where human inputs and artificial intelligence routines intersect4.  
To facilitate deterministic orchestration, matchmaking, and state recovery, every hospital instance is strictly defined by the following systemic parameters:

| Parameter | Type | Architectural Definition and Function |
| :---- | :---- | :---- |
| **Instance Identifier** | UUID v4 | A cryptographically secure, globally unique string managed exclusively by the backend control plane. It is never exposed to the client, preserving diegetic immersion and preventing targeted server harassment1. |
| **Human Capacity** | Integer | A hard-coded constraint locked at exactly 10\. The connection orchestrator outright rejects incoming socket requests that exceed this limit, forcing a queue or redirect state. |
| **NPC Population Budget** | Integer | A dynamic threshold (ranging from 2 to 15\) regulating the maximum number of active AI entities. The budget scales inversely with human occupancy to maintain consistent social density without inducing CPU exhaustion or cognitive overload6. |
| **Story Phase** | Enumeration | Defines the narrative context (e.g., PHASE\_1\_ONBOARDING, PHASE\_2\_ESCALATION). Matchmaking algorithms use this to ensure players are never placed into environments where the physical state contradicts their personal progression. |
| **Difficulty Band** | Categorical | Indexes the aggression of hostile AI and puzzle complexity, ensuring veterans and novices are not mismatched in ways that disrupt the intended user experience. |
| **Creation Time** | UTC Timestamp | Records the initialization of the server process. Utilized by the garbage collection systems to cull stagnant instances and evaluate long-term server health. |
| **Activity State** | Boolean | Indicates whether the instance is actively processing game loops or has entered a suspended, resource-saving idle mode due to lack of human presence. |
| **Joinability State** | Boolean | Signals to the matchmaking allocator whether the instance can accept new routing requests. Toggleable during critical narrative transitions or shutdown sequences. |
| **Event State** | JSON Blob | Serializes localized, non-persistent environmental changes (e.g., triggered alarms, open doors) that reset entirely upon the termination of the instance. |
| **Cleanup State** | Enumeration | Tracks the asynchronous flushing of critical telemetry and delayed persistence queues before the instance is permitted to deallocate memory and self-destruct. |
| **Archival Conditions** | Logic Block | The explicit physical or temporal thresholds that mandate termination, such as maintaining zero human occupancy for 300 seconds, or detecting a fatal memory leak. |

#### **2\. Persistence Domain Model**

To guarantee that a player never loses personal progress due to the volatile nature of instanced environments, all game state is strictly partitioned into distinct persistence domains. Data consistency across these domains relies on a distributed database architecture utilizing the Saga pattern for long-running, cross-domain transactions7. This ensures that if a server crashes, the system can gracefully rollback or commit pending changes without corrupting the player's profile.

##### **State Classification**

| Domain | Scope and Storage Mechanism | Example Entities |
| :---- | :---- | :---- |
| **Personal Persistent** | Tied to the user's Account UUID. Stored in high-durability, distributed NoSQL or relational databases. | Inventory contents, learned narrative clues, relationship affinity with NPCs, completed objectives, accessibility settings, account reputation. |
| **Instance Persistent** | Tied to the Instance UUID. Stored in rapid, in-memory data stores (e.g., Redis) and localized server RAM. | State of unlocked doors, current staff shift, active emergencies, communal resource depletion, positions of dropped physical items, damaged equipment. |
| **Global Persistent** | Tied to the game universe. Stored in a master relational database and cached globally via Content Delivery Networks. | Hospital-wide event calendars, economic configurations, overarching narrative seasons, aggregate community outcomes. |
| **Ephemeral** | Tied strictly to the active network session. Held exclusively in the runtime memory of the instance server. | Typing indicators, momentary spatial coordinates, short-lived object physics, voice activity detection states, localized proximity presence. |

##### **Conflict Resolution Protocols**

When overlapping states interact, the architecture demands deterministic resolution to prevent duplication exploits or narrative incoherence.  
The interaction between Personal Persistent state and Instance Persistent state is governed by an **Absolute Override** policy in favor of the player. If a player’s Personal state indicates they have already bypassed a security door, the instance must render that door accessible to that specific player, even if the Instance state considers the door locked for the broader room. To prevent sequence breaking for other players, the UI suppresses the interaction prompt for the completed player, rendering the objective inert to them while allowing others to complete it.  
Item transfers from the Personal domain to the Instance domain (e.g., dropping a medical kit on the floor) utilize a two-phase commit protocol to prevent duplication7. The item is initially locked in the Personal database, instantiated physically within the Instance memory, and only permanently deleted from the Personal database upon an explicit acknowledgment from the instance server. If the instance crashes before acknowledgment, the lock is released, and the item remains in the player's inventory. Ephemeral state conflicts, such as positional disagreements between the client and server, always default to the server's authoritative truth, forcing a client-side rollback to mitigate speed hacks or desynchronization3.

#### **3\. Player Placement Algorithm**

The placement policy dictates how incoming players and parties are routed to available hospital instances. Rather than relying on simple round-robin or purely latency-driven assignments, the system treats placement as a multi-objective optimization problem, conceptually similar to a 0-1 Knapsack algorithm9. The algorithm evaluates hard constraints that outright disqualify instances, followed by soft constraints that generate a compatibility score, preferring healthy backfilling over the aggressive creation of empty instances.

##### **Language-Neutral Placement Pseudocode**

FUNCTION FindOptimalHospital(PartyRequest): // 1\. Evaluate Reconnect Reservations IF PartyRequest.HasValidReconnectToken(): TargetInstance \= GetInstanceByID(PartyRequest.ReconnectInstanceID) IF TargetInstance.IsActive() AND TargetInstance.HasReservation(PartyRequest.PlayerID): RETURN TargetInstance

ValidInstances \= \[\]  
AvailableInstances \= Matchmaker.GetInstancesInRegion(PartyRequest.Region)

// 2\. Hard Constraint Filtering  
FOR Instance IN AvailableInstances:  
    IF (Instance.HumanCount \+ PartyRequest.Size) \> 10:  
        CONTINUE // Exceeds physical capacity  
      
    IF Instance.StoryPhase \!= PartyRequest.StoryPhase:  
        CONTINUE // Narrative mismatch  
          
    IF HasIntersection(Instance.PlayerIDs, PartyRequest.BlockedIDs):  
        CONTINUE // Violates blocked-player safety  
          
    IF Instance.JoinabilityState \== FALSE:  
        CONTINUE // Instance locked for events or draining  
          
    IF PartyRequest.RequiresQuarantine \!= Instance.IsQuarantine:  
        CONTINUE // Moderation status mismatch  
          
    ValidInstances.Append(Instance)  
      
// 3\. Soft Constraint Scoring  
BestInstance \= NULL  
HighestScore \= \-9999

FOR Instance IN ValidInstances:  
    Score \= 0  
      
    // Social Density Target: Prefer instances that will be filled close to 10  
    DensityRatio \= (Instance.HumanCount \+ PartyRequest.Size) / 10.0  
    Score \+= DensityRatio \* 100   
      
    // Language Alignment  
    IF Instance.MajorityLanguage \== PartyRequest.Language:  
        Score \+= 30  
          
    // Tutorial Isolation  
    IF PartyRequest.IsTutorial AND Instance.HumanCount \> 0:  
        Score \-= 500 // Severely penalize placing onboarding players in active rooms  
          
    // Instance Health Assessment  
    IF Instance.ServerTickRate \< TargetTickRate OR Instance.Uptime \> MaxUptime:  
        Score \-= 75 // Penalize degrading or soon-to-drain servers  
          
    IF Score \> HighestScore:  
        HighestScore \= Score  
        BestInstance \= Instance

// 4\. Execution and Fallback  
IF BestInstance \!= NULL:  
    BestInstance.ReserveSlots(PartyRequest.Size)  
    RETURN BestInstance  
ELSE:  
    // No compatible match found; provision a new environment  
    NewInstance \= Orchestrator.CreateInstance(PartyRequest.StoryPhase, PartyRequest.Region)  
    NewInstance.ReserveSlots(PartyRequest.Size)  
    RETURN NewInstance

##### **Constraint Rationale**

The algorithm ensures that an eleventh compatible player is never forced into a full room; they are deterministically routed to a newly created instance. Furthermore, new players are heavily penalized from joining instances where the local tutorial phase has elapsed, guaranteeing that the onboarding sequence remains coherent. Latency matching is handled implicitly by narrowing the initial search pool to the closest geographical orchestration region, avoiding the need for invasive, real-time client IP profiling10.

#### **4\. Party Cohesion Sequence**

Preserving the social fabric of pre-formed groups is paramount. Parties are treated as indivisible atomic units by the matchmaking allocator. The system enforces strict behavioral sequences for all permutation of party dynamics.

##### **Joining Dynamics**

When a single player joins, they are subjected to standard backfilling logic, gravitating toward instances with 8 or 9 players to achieve the social density target. When a party of two to ten friends queues together, the algorithm evaluates their combined size. If no single active instance possesses the required 10 \- N available slots, the system bypasses existing instances and provisions a fresh hospital instance exclusively for them. The system will never split a party to populate fragmented server slots11.  
If a party exceeds the hard cap of 10 players, the interface intervenes prior to the matchmaking request. It presents a clear, non-destructive prompt requiring the group to designate a secondary leader, functionally splitting the party into two distinct queues. These newly formed groups are then assigned a shared narrative tag, increasing the probability they are placed into parallel instances of the same story phase, even if they cannot share the exact physical space.  
When a player attempts to join a friend whose hospital is currently full, the joining player is placed into a localized priority queue. If an occupancy slot fails to open within 60 seconds, the system dispatches a diegetic prompt to the friend's party leader, suggesting a "transfer to a new ward." If accepted, the active party and the new friend are seamlessly migrated together to a newly created instance, leaving the previous instance to backfill naturally.

##### **Fragmentation and Dissonance Handling**

In circumstances where a party member reaches a different story phase mid-session, the interface issues a discrete warning. The player with lower progression retains their Personal Persistent state, but participates in the advanced instance as a "guest observer," preventing sequence breaking while maintaining social cohesion.  
If a party leader leaves the instance or disconnects, leadership is deterministically reassigned to the member with the longest current session uptime. Should the system request an instance migration (e.g., due to rolling server updates) and a player declines, that player is gracefully dropped from the party unit and transitioned into a solo queue, while the remainder of the group proceeds to the new instance. Furthermore, if a player actively blocks another participant currently in their party, the system immediately dissolves the party link and forces a physical separation, migrating the blocking player to a parallel instance to ensure immediate social safety.

#### **5\. Reconnect Handling and Anti-Duplication**

Network instability presents a critical risk of item duplication and avatar cloning, particularly in engines like Unity or Unreal where standard network hooks may blindly instantiate a new GameObject upon client connection12. To prevent this, the architecture entirely decouples the logical Player Entity from the active Network Socket.

##### **The Reconnect Lifecycle**

Upon detecting a socket closure, the instance server suppresses standard destruction routines. Instead, the player's avatar is transitioned into a paused, invulnerable, and highly transparent physical state. Simultaneously, the system generates a Reconnect Reservation tied strictly to the player's Account UUID, valid for a Grace Period of 180 seconds.  
When the client re-establishes a connection, the orchestrator evaluates the incoming Account UUID. To provide anti-abuse protection against rapid reconnect cycling (e.g., lag switching), the orchestrator limits reconnection attempts to three per 60-second window; exceeding this triggers a 5-minute session lockout. Furthermore, the orchestrator guarantees duplicate-session rejection by forcefully terminating any lingering, unresponsive sockets associated with that Account UUID before granting the new connection14.

##### **State Restoration Scenarios**

The routing of the reconnected player depends entirely on the status of the original instance:

* **Instance is Active and Grace Period Valid:** The player is routed directly back to the original instance. The server re-maps the new network connection to the dormant Player Entity. Positional coordinates, inventory status, and active NPC conversations are instantly restored, creating a seamless experience.  
* **Instance is Active but Full (Grace Period Expired):** The reservation is voided. The player cannot bypass the 10-person limit. They are processed as a new arrival and placed via standard matchmaking, potentially landing in a different hospital instance.  
* **Instance was Destroyed or Archived:** If the original instance no longer exists, the player's previous coordinates are discarded to prevent spawning out-of-bounds. The player is assigned to a "Safe Fallback Location," such as the hospital lobby or a designated staff breakroom, and placed into a new instance matching their persistent story phase.  
* **Server Restart (Global Outage):** Following a total infrastructure reboot, all ephemeral instance data is lost. Players connecting post-restart inherit the Safe Fallback Location and are distributed into newly warmed instances, utilizing jittered reconnection delays (randomized 1-5 second offsets) to prevent thundering herd scenarios against the matchmaking database15.

#### **6\. NPC Population and Conversation Budget**

Populating the hospital with AI-driven NPCs is essential for maintaining the illusion of a living world, but it introduces severe risks regarding computational overhead, room overcrowding, and chaotic multi-party audio6. The architecture resolves this through dynamic population budgeting and strict conversation coalescing.

##### **Population Distribution and Culling**

NPCs are categorized into two tiers: Core NPCs and Ambient NPCs. Core NPCs, such as the Head Surgeon or Lead Investigator, are tied directly to the active Story Phase and must exist in every compatible instance. They are pinned to specific operational zones and drive narrative progression. Ambient NPCs, such as wandering patients or administrative staff, serve as dynamic filler.  
To maintain social density without overwhelming the room, the Ambient NPC budget operates inversely to human occupancy. If an instance contains 1 human player, the system may spawn up to 15 Ambient NPCs. As human players join, Ambient NPCs are diegetically culled—they navigate toward exit elevators and de-spawn. Conversely, to avoid expensive AI pathfinding and Large Language Model (LLM) generation in empty rooms, the server utilizes aggressive frustum and occlusion culling17. When a room lacks human presence, all contained NPCs are suspended; their schedules are calculated deterministically via background math rather than physical simulation, saving massive computational overhead.

##### **Conversation Budgets and Turn-Taking**

When leveraging LLM-backed dialogue, traditional Voice Activity Detection (VAD) struggles in multi-party settings, often treating every pause as an invitation to interrupt16. To prevent this, the architecture enforces a "Context-Aware Turn-Taking" model. The AI remains in a passive listening state until explicitly addressed by name, targeted via a direct interaction input, or presented with a hard silence threshold of 1.5 seconds following an interrogative phrase.  
When multiple humans address the same character simultaneously, the system prevents the NPC from fragmenting into multiple, disjointed private conversations. Instead, it utilizes Conversation Coalescing. The server aggregates the inputs of all proximate players into a single, structured LLM prompt (e.g., Player A asks: "Where is the key?" Player B says: "Hurry up."). The NPC then delivers a shared, unified response to the group, addressing both concerns naturally19.  
To prevent one player from monopolizing a critical Core NPC, the system implements a "Fair Turn" interaction queue20. If a player engages an NPC for more than 45 continuous seconds while another player is standing within the interaction radius, the NPC will execute a diegetic break. The NPC will state, "Hold that thought, I need to see what your colleague needs," and forcefully shift its physical orientation and attention to the waiting player, ensuring equitable access to narrative progression.

#### **7\. Instance Lifecycle State Machine**

The operational lifecycle of a hospital instance is managed by a Kubernetes-native control plane, mapping conceptual game states to concrete infrastructure transitions to ensure high availability and graceful degradation22.

| State | Trigger Condition | Action and Failure Handling |
| :---- | :---- | :---- |
| **CREATING** | Matchmaker requests capacity. | Infrastructure provisions a new pod and allocates network ports. *Failure:* If provisioning times out (\>10s), the pod is killed, and players are re-queued. |
| **WARMING** | Server process initializes successfully. | The instance connects to Global Persistent databases, fetches seasonal parameters, and spawns the initial NPC budget. Joinability is set to FALSE. *Failure:* Database timeout transitions the instance directly to DRAINING. |
| **JOINABLE** | Warming sequence completes. | The instance registers with the allocator. It accepts human connections (1 to 7 players). AI behavioral loops are fully activated. |
| **NEAR\_CAPACITY** | Occupancy reaches 8 or 9\. | The matchmaker deprioritizes this instance for large parties but boosts priority for solo backfilling. Ambient NPCs are actively culled. |
| **FULL** | Occupancy reaches 10\. | Joinability flag set to FALSE. The instance is removed from general matchmaking, holding capacity only for active Reconnect Reservations. |
| **DRAINING** | Narrative phase complete or rolling update initiated. | Accepts no new players25. Active players are presented with a diegetic migration event (e.g., "Shift Change"). |
| **QUIESCENT** | Human occupancy drops to 0\. | Pauses all physics and AI processing to conserve CPU. A 5-minute countdown begins. If a player reconnects, transitions back to JOINABLE. |
| **ARCHIVING** | Quiescent timer expires. | Flushes all remaining telemetry and Instance Persistent data to long-term storage. Prepares memory for deallocation. |
| **TERMINATED** | Archival sequence succeeds. | The orchestrator terminates the process, reclaiming compute resources for future scaling. |
| **RECOVERY** | Internal fatal error detected (e.g., memory leak). | Halts simulation. Dispatches all connected clients to the Matchmaker with a Priority\_Migration flag. Transitions to ARCHIVING for forensics. |

#### **8\. Social Safety and Moderation**

Given the intimate scale of a 10-player instance, abusive behavior carries a disproportionately high impact. The architecture provides instance-level tools designed to neutralize toxicity without relying on invasive identity verification or IP tracking27.

##### **Protective Mechanisms**

Players have immediate access to spatial muting and blocking. When Player A blocks Player B, the instance executes a temporary room separation (phasing). Player B becomes entirely invisible and inaudible to Player A, and their physical collisions are disabled, allowing Player A to pass through them freely. The matchmaker caches this blocklist (using salted hashes to preserve privacy) to ensure these two players are never placed in the same instance again.  
To prevent groups of griefers from capturing every doorway or surrounding a critical NPC to block access, the physics engine employs a time-decaying collision model. If a player occupies a high-traffic threshold (like a doorframe) without significant movement for more than 5 seconds, their collision mesh softens, allowing other players to push through them unimpeded.  
Moderator observation is supported via an invisible, non-colliding "ghost" mode. Moderators can audit voice and text logs retroactively, as the ephemeral state buffers the last 60 seconds of interaction in RAM before discarding it. Automatic harassment-rate limits restrict the frequency of repeated interactions (e.g., spamming an item drop or repeatedly triggering a localized alarm), temporarily locking the action if executed more than five times in ten seconds. Finally, onboarding players are granted strict protection; the algorithm heavily penalizes placing veterans into instances flagged for tutorials, insulating new users during their most vulnerable learning phase.

#### **9\. Scale Model and Concurrency Matrix**

The architecture must scale seamlessly from a solitary user up to a massive concurrent player base. By modeling specific concurrency thresholds, unique lifecycle risks are identified and mitigated at the network layer4.

| Concurrency (CCU) | Est. Instances | Primary Lifecycle Risk | Architectural Mitigation |
| :---- | :---- | :---- | :---- |
| **1 Human** | 1 | Empty instance timeout loops (QUIESCENT state thrashing). | Ensure rapid transition to ARCHIVING to save compute costs. Rely heavily on Ambient NPCs for density. |
| **9 Humans** | 1 | Room overcrowding; lack of available NPCs. | Prune ambient NPCs dynamically. Matchmaker highly favors this instance to reach the perfect 10 capacity. |
| **10 Humans** | 1 | Instance becomes FULL. No room for immediate reconnects. | The 180-second Grace Period reserves a slot. If a player leaves, that slot remains protected for the duration before opening. |
| **11 Humans** | 2 | Party split anxiety; isolation of the 11th player. | The 11th player is placed in a new instance. The Matchmaker prioritizes backfilling the new instance to prevent them from remaining alone. |
| **21 Humans** | 3 | Blocklist gridlock. | If Player 21 is blocked by someone in both existing 10-player instances, a 3rd instance spins up immediately to accommodate them safely. |
| **100 Humans** | 10 \- 15 | Database write contention for Instance state saves. | Batch asynchronous DB writes every 5 seconds. Use Redis for in-memory ephemeral state locking. |
| **1,000 Humans** | 100 \- 120 | Thundering herd during rolling server restarts. | Implement client-side reconnect jitter (randomized 1-5 second delays) to prevent overwhelming the matchmaking database15. |
| **10,000 Humans** | 1,000 \- 1,200 | Matchmaker CPU exhaustion / Kubernetes Pod Limits. | Shard the matchmaker geographically. Implement aggressive bin-packing scheduling to optimize node utilization22. |

#### **10\. Privacy-Safe Telemetry Dictionary**

Balancing the game economy, evaluating matchmaking efficiency, and monitoring server health requires robust telemetry. However, to meet non-negotiable privacy boundaries, the system explicitly forbids browser fingerprinting, IP retention, and real-world identity tracking. All metrics are aggregated globally or tied to ephemeral session tokens that discard automatically.

| Metric Identifier | Description | Data Type | Privacy and Retention Control |
| :---- | :---- | :---- | :---- |
| occ\_curr\_h | Current human occupancy per instance. | Integer (0-10) | Aggregated globally. Sampled every 60 seconds. |
| inst\_create\_r | Instance creation rate per minute. | Float | System metric. No player data attached. |
| inst\_close\_r | Instance closure rate per minute. | Float | System metric. No player data attached. |
| q\_time\_ms | Matchmaking queue time latency. | Integer | Tied to ephemeral session ID. Discarded post-placement. |
| party\_split\_pct | Percentage of parties \>10 requiring splits. | Float | Count-based aggregation. No user tags. |
| recon\_succ\_b | Reconnect success rate after disconnect. | Boolean | Session token hash. Retained for 24 hours for debugging. |
| migr\_fail\_count | Failed migrations due to capacity or timeout. | Integer | System metric triggered on RECOVERY timeout. |
| empty\_inst\_s | Duration an instance remains at 0 occupancy. | Integer | Measured during QUIESCENT state. Discarded after 24h. |
| npc\_lat\_ms | NPC response latency (LLM generation delay). | Integer | Excludes conversational transcripts. pure timing data. |
| blk\_col\_r | Blocked-player collision prevention rate. | Integer | Blocklists are hashed and salted; true IDs never logged. |
| onb\_comp\_b | Onboarding completion status. | Boolean | Tied strictly to Account UUID progression flags. |
| dep\_force\_b | Player departure post-forced migration. | Boolean | Checks for disconnects within 2 minutes of migration. |
| room\_over\_b | Room overcrowding trigger. | Boolean | Geofence counter when humans \+ NPCs exceed density limit. |
| npc\_cont\_r | Critical-NPC contention rates. | Integer | Interaction queue size when \>1 player waits in an NPC zone. |

#### **11\. Player-Facing Queue and Migration Copy**

To maintain the narrative immersion of Rogue Intelligence, all technical operations—such as matchmaking, instance scaling, server crashing, and reconnecting—must be obscured behind diegetic language. The UI must never expose terms like "shard," "instance," "latency," or "matchmaking" to the user, as doing so shatters the illusion of the hospital environment1.

##### **Matchmaking and Queuing**

When a player initiates a session, the system replaces traditional loading screens with narrative context.

* **Standard Join (Queuing):** "Checking in at the front desk. Please take a seat in the waiting area..."  
* **Extended Wait Time (High Server Load):** "The ER is currently at capacity. The triage nurse will call your name shortly."  
* **Party Joining:** "Admitting your group. Keeping your paperwork together..."

##### **Server Lifecycle and Migration**

When the infrastructure requires scaling or maintenance, the transitions are presented as hospital procedures.

* **Instance Draining (Rolling Restart):** "Attention all staff: Shift change in progress. Please proceed to the newly assigned ward."  
* **Forced Migration (Server Crash/Recovery):** "Emergency protocols activated. You have been relocated to a secure sector."  
* **Friend Requesting Migration (Full Server):** "Your colleague is waiting in the lobby, but this ward is locked down. Transfer to a new ward to meet them?"

##### **Disconnects and Reconnects**

Handling network drops requires framing the loss of control as a physical ailment within the game world.

* **Player Disconnects (Viewed by others):** The player's avatar slumps slightly. "Dr. \[Name\] is unresponsive."  
* **Player Reconnects (Viewed by the user):** "You blacked out for a moment. Catching your breath..."

##### **AI Transparency and Social Safety**

The architecture strictly requires that players are informed when interacting with an AI, without resorting to hidden mechanics that impersonate humans. This is achieved through subtle UI indicators.

* **AI Identification:** All LLM-driven characters bear a stylized "Employee ID Badge" icon next to their nameplate. When a player hovers over or focuses on the badge, a tooltip reads: *Synthesized Hospital Staff (AI).* This fulfills the transparency requirement elegantly.  
* **AI Monopolization Break:** When the system forces an NPC to switch targets due to time monopolization, the UI briefly displays contextual text: *(The staff member appears overwhelmed by the crowd).*  
* **Reporting/Blocking:** When a player utilizes the block or report function, the UI frames it narratively: "Filing an HR grievance. This individual has been reassigned to a different shift." The offending player then smoothly fades out of the local instance, driven by the network-layer block.

###### **Works cited**

1. How does an instance server actually work? \- Elder Scrolls Online forums, [https://forums.elderscrollsonline.com/en/discussion/689343/how-does-an-instance-server-actually-work](https://forums.elderscrollsonline.com/en/discussion/689343/how-does-an-instance-server-actually-work)  
2. Shard (database architecture) \- Grokipedia, [https://grokipedia.com/page/Shard\_(database\_architecture)](https://grokipedia.com/page/Shard_\(database_architecture\))  
3. How Do Game Servers Work? Understanding Multiplayer Servers \- TechTide Solutions, [https://techtidesolutions.com/blog/how-do-game-servers-work/](https://techtidesolutions.com/blog/how-do-game-servers-work/)  
4. Making and Scaling a Game Server in Kubernetes using Agones \- /home/noe, [https://noe-t.dev/posts/making-and-scaling-a-game-server-in-k8s-using-agones/](https://noe-t.dev/posts/making-and-scaling-a-game-server-in-k8s-using-agones/)  
5. MMO Shards Question : r/MMORPG \- Reddit, [https://www.reddit.com/r/MMORPG/comments/gmg8b9/mmo\_shards\_question/](https://www.reddit.com/r/MMORPG/comments/gmg8b9/mmo_shards_question/)  
6. Conversation dynamics in a multiplayer video game with knowledge asymmetry \- PMC, [https://pmc.ncbi.nlm.nih.gov/articles/PMC9669907/](https://pmc.ncbi.nlm.nih.gov/articles/PMC9669907/)  
7. Modeling Saga as a State Machine \- DZone, [https://dzone.com/articles/modelling-saga-as-a-state-machine](https://dzone.com/articles/modelling-saga-as-a-state-machine)  
8. Fog of War, Flood of Packets: Unravelling the System Design of an MMORTS \- Medium, [https://medium.com/@remisharoon/fog-of-war-flood-of-packets-unravelling-the-system-design-of-an-mmorts-0cc32063d716](https://medium.com/@remisharoon/fog-of-war-flood-of-packets-unravelling-the-system-design-of-an-mmorts-0cc32063d716)  
9. skill based matchmaking algorithm design \- Reddit, [https://www.reddit.com/r/algorithms/comments/1hszvbz/skill\_based\_matchmaking\_algorithm\_design/](https://www.reddit.com/r/algorithms/comments/1hszvbz/skill_based_matchmaking_algorithm_design/)  
10. What Is Skill-Based Matchmaking (SBMM)? \- PubNub, [https://www.pubnub.com/blog/skill-based-matchmaking-explained/](https://www.pubnub.com/blog/skill-based-matchmaking-explained/)  
11. Queuing and Matchmaking | League of Legends Wiki \- Fandom, [https://leagueoflegends.fandom.com/wiki/Queuing\_and\_Matchmaking](https://leagueoflegends.fandom.com/wiki/Queuing_and_Matchmaking)  
12. Reconnecting mid-game | Netcode for GameObjects | 2.4.4 \- Unity \- Manual, [https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.4/manual/advanced-topics/reconnecting-mid-game.html](https://docs.unity3d.com/Packages/com.unity.netcode.gameobjects@2.4/manual/advanced-topics/reconnecting-mid-game.html)  
13. C\# Photon Networking \- Preventing duplicate GameObjects from spawning on Join., [https://discussions.unity.com/t/c-photon-networking-preventing-duplicate-gameobjects-from-spawning-on-join/187115](https://discussions.unity.com/t/c-photon-networking-preventing-duplicate-gameobjects-from-spawning-on-join/187115)  
14. Severe issue with online multiplayer preventing any amount of players above 2 \- Reddit, [https://www.reddit.com/r/necrodancer/comments/wp92ko/severe\_issue\_with\_online\_multiplayer\_preventing/](https://www.reddit.com/r/necrodancer/comments/wp92ko/severe_issue_with_online_multiplayer_preventing/)  
15. Switchboard: A Matchmaking System for Multiplayer Mobile Games, [https://synrg.csl.illinois.edu/papers/manweiler11switchboard.pdf](https://synrg.csl.illinois.edu/papers/manweiler11switchboard.pdf)  
16. Speak or Stay Silent: Context-Aware Turn-Taking in Multi-Party Dialogue \- arXiv, [https://arxiv.org/html/2603.11409v1](https://arxiv.org/html/2603.11409v1)  
17. Game-Inspired Autonomy in Language Teaching and Learning \- The FLTMAG, [https://fltmag.com/game-inspired-autonomy/](https://fltmag.com/game-inspired-autonomy/)  
18. Multimodal Transformer Models for Turn-taking Prediction: Effects on Conversational Dynamics of Human-Agent Interaction during C \- Casey Bennett, [https://www.caseybennett.com/uploads/Multimodal\_Transformer\_Turn-Taking\_for\_Robots\_Preprint.pdf](https://www.caseybennett.com/uploads/Multimodal_Transformer_Turn-Taking_for_Robots_Preprint.pdf)  
19. DialogLab: Authoring, Simulating, and Testing Dynamic Human-AI Group Conversations \- Erzhen Hu, [https://erzhenh.com/pdfs/uist25\_DialogLab.pdf](https://erzhenh.com/pdfs/uist25_DialogLab.pdf)  
20. How do I handle large conversations with multiple NPCs? \- RPG Stack Exchange, [https://rpg.stackexchange.com/questions/50946/how-do-i-handle-large-conversations-with-multiple-npcs](https://rpg.stackexchange.com/questions/50946/how-do-i-handle-large-conversations-with-multiple-npcs)  
21. How do you handle dialogs with multiple NPC's? : r/DMAcademy \- Reddit, [https://www.reddit.com/r/DMAcademy/comments/1jthuhw/how\_do\_you\_handle\_dialogs\_with\_multiple\_npcs/](https://www.reddit.com/r/DMAcademy/comments/1jthuhw/how_do_you_handle_dialogs_with_multiple_npcs/)  
22. GameServerAllocation Specification \- Agones, [https://agones.dev/site/docs/reference/gameserverallocation/](https://agones.dev/site/docs/reference/gameserverallocation/)  
23. System Diagram \- Agones, [https://agones.dev/site/docs/advanced/system-diagram/](https://agones.dev/site/docs/advanced/system-diagram/)  
24. GameServer Specification \- Agones, [https://agones.dev/site/docs/reference/gameserver/](https://agones.dev/site/docs/reference/gameserver/)  
25. a dictionary PDF, [https://www.bluefirereader.com/certification/dictionary.pdf](https://www.bluefirereader.com/certification/dictionary.pdf)  
26. KubeCon \+ CloudNativeCon Europe 2026: Full Schedule, [https://kccnceu2026.sched.com/list/descriptions](https://kccnceu2026.sched.com/list/descriptions)  
27. “I Don't Have Faith in the Developers to Use My Feedback”: Understanding Player Values and Expectancy for Reporting Systems in Video Games \- arXiv, [https://arxiv.org/html/2605.02842v2](https://arxiv.org/html/2605.02842v2)  
28. (PDF) Transparency, Fairness, and Coping: How Players Experience Moderation in Multiplayer Online Games \- ResearchGate, [https://www.researchgate.net/publication/368358442\_Transparency\_Fairness\_and\_Coping\_How\_Players\_Experience\_Moderation\_in\_Multiplayer\_Online\_Games](https://www.researchgate.net/publication/368358442_Transparency_Fairness_and_Coping_How_Players_Experience_Moderation_in_Multiplayer_Online_Games)  
29. Metrics \- Agones, [https://agones.dev/site/docs/guides/metrics/](https://agones.dev/site/docs/guides/metrics/)

## Decisions or Recommendations

- Use only the claim dispositions in [Reviewed Synthesis](#reviewed-synthesis) as current guidance.
- Preserve the immutable source file and source checksum; corrections belong in this canonical wrapper and the claim-review register.
- Re-review legal, agency, clinical, age/consent, vendor, product, market, and software claims before each public release.
- Apply equal evidence burdens and explicit uncertainty across jurisdictions, institutions, cultures, and affected communities.
- Keep implementation decisions in active `.uai` memory and verified repository tests rather than treating research prose as executable authority.

## Risks and Limitations

- The review is scoped to high-impact and publication-relevant claims; it is not legal advice, medical advice, a regulatory conformity assessment, or independent product certification.
- External sources and laws can change after the review date; later reuse requires freshness checks.
- The preserved source body may still contain claims that were not selected for public reuse. Their presence is provenance, not endorsement.
- Automated checks cannot establish human comprehension, lived-experience acceptability, native assistive-technology behavior, or real-world player outcomes.
- Archive provenance does not classify the report as Saudi-specific; its subject and claim boundaries remain independent of the container name.

## Validation Performed

- Completed a structured claim register with **5** dispositions for this report.
- Compared date-sensitive governance, agency, accessibility, mental-health-rights, child-privacy, age-assurance, and local-inference claims with current primary or authoritative sources where applicable.
- Applied international comparative-fairness, dignity, consent, accessibility, non-stigmatization, and non-actionability review.
- Confirmed the preserved source file remains individually addressable and its recorded SHA-256 lineage is unchanged.
- Local report-template, backlink, pointer, checksum, link, anchor, syntax, discovery, and package checks are rerun during release finalization.

## Memory References

- [architecture.uai](../../../.uai/architecture.uai#site-and-memory-architecture)
- [performance-audit.uai](../../../.uai/performance-audit.uai#performance-audit)
- [world-context.uai](../../../.uai/world-context.uai#world-context)

## Related Durable Documents

- [Claim-level review and comparative fairness audit](claim-level-review-and-comparative-fairness-audit.md#findings)
- [Hero Clarity, Report Integration, and UAI Routing Report](hero-clarity-report-integration-and-uai-routing-report.md#executive-summary)
- [Provided-report intake audit](../research/provided-report-intake-audit.md#current-94-file-archive-intake)
- [Source-to-report map](../research/source-to-report-map.md#source-to-report-map)
- [Split-memory architecture](../architecture/split-memory-architecture.md#architecture)

## Supersession Status

Current as the canonical durable repository copy and reviewed publication wrapper for 2.0.13-wip. The preserved source analysis is not deleted or rewritten. A later claim review may supersede individual dispositions while retaining this provenance and stable report identity.