R — choose S3 only when the interaction needs people together at the same time. Add live synchronization because simultaneity creates the value, not because multiplayer is available.

Two visitors share one conceptual project. Neither connects directly to the other in the diagram. The highlighted shared experience is the outcome, not a claim about the network’s topology or transport. The footer explicitly calls it a conceptual capability map, dated 2026-09-06.
The question and the minimum
“Does the core interaction require people at the same time?” The minimum is browser interaction plus shared-state rules, access policy, and synchronization. Define who may participate, what state is shared, how conflicts resolve, which outcomes are authoritative, and what reconnect means.
Shared outcomes must not be shown as authoritative before trusted confirmation. Connection status must be truthful. Late arrivals, duplicate input, a dropped connection, or publication during use must not create invented outcomes, duplicate committed actions, or unexplained losses.
Declared nodes and edges
| Visitor endpoint | Shared endpoint | Meaning |
|---|---|---|
| VISITOR A | SHARED PROJECT | Bidirectional edge labeled “sync” |
| VISITOR B | SHARED PROJECT | Bidirectional edge labeled “sync” |
The JSON record counts two bidirectional links, not four separately listed directed edges. Its checks require exactly two visitors connected through the shared project, heads at both ends of both links, and no direct visitor-to-visitor edge. No peer-to-peer implementation, anti-cheat property, or transport guarantee follows from the drawing.
The source manifest records a copy decision: the redundant “Presence + live state” caption was omitted to retain the safety-complete rendering, because the sync links already express live sharing. This explains a source artwork choice, not a new critique.
Persistence, moderation, and AI are conditional
Save history only if the outcome needs it. S3 does not automatically inherit S2’s database. Moderate in proportion to exposure and harm; if participants can publish unwanted content or affect others, define appropriate restrictions and operator powers. A feed is not required.
AI remains optional and independent. If enabled, the same cost, input preservation, malformed-result, duplicate-call, and safe-output requirements apply as in any other scope.
Stop condition
Stop at the smallest safe shared loop: two visitors can complete the intended interaction through disconnect and rejoin. The poster’s checks are two visitors, late join, disconnect, and rejoin. experience-and-acceptance > Acceptance cases A8 covers agreed state and conflict rules; A9 covers disconnect, rejoin, and publishing during use; A6 applies to protected operations. All-scope and conditional AI/content cases remain relevant.
D: the August 2026 update describes better reconnection and publishing behavior. That announcement is not an independently measured latency, capacity, transaction, backup, or anti-cheat guarantee. See evidence-and-limits for what remains unknown.
Source basis: PRD.md sections 1, 4, 6–8; scoped-posters.json scope S3; scope-3-play-together.png. Compare scope-1-play-now and scope-2-keep-what-matters without treating them as prerequisite releases.
Presence, shared updates, and authority are different
The September 10 material separates three problems: document conflicts, presence indicators, and trusted game rules. The Darkroom’s RoomHub is a same-page teaching relay with ordered updates, heartbeat presence, and latest-state restoration; it is not real networking/authentication or server-authoritative anti-cheat. Gaming Stax’s referee is also explicitly local, with no Nakama server connection.
For a real authoritative game, clients send intentions and custom server rules validate actions and own outcomes/rewards/scores. Relayed matches do not validate gameplay automatically. Matchmaker tickets do not by themselves spawn a match: the corrected gaming artifact identifies custom registerMatchmakerMatched integration. RPC may use an active socket; match-data opcodes are a different operation.
Rendering cadence and server tick cadence are separate; use the lowest tick rate that meets gameplay. Reconnection means transport restoration plus returning-player admission, authoritative snapshot delivery, and duplicate-result handling. Persistence of results/checkpoints is explicit. Start with one Nakama node; enterprise clustering is separate. Its TypeScript runtime is an embedded VM, not Node/browser; client physics is not server authority, and complex trusted physics may require a dedicated simulation process.
The source’s future first-playable contract is authenticate → join one authoritative match → play → reconnect/resynchronize → server records result → leaderboard, with two players and one mode. Invalid-action rejection, rejoin and duplicate-result handling precede economy, inventory, clans or tournaments. This contract has not been exercised here and is not one of the later three strategic plans.