discipline

analyst-desk copy rather than a live conversation.

Vocabulary discipline

A few rules-of-the-road that keep the language tight across docs and prompts:

1. Prefer the canonical term over a paraphrase. "Priors" not "accumulated knowledge" or "queue" or "between-session input"; "readings" not "scenario picker".
2. System / World / Fate are always capitalised when naming the forces — even mid-sentence — to distinguish from the everyday senses of those words. "the System force" / "the domain's world is rich" (lowercase only when it's clearly the noun, not the force).
3. "Domain" and "domain" are interchangeable. Domain is the canonical case study; domain is the underlying abstraction. Use whichever fits register. Avoid "model" or "simulation" as substitutes — both have other meanings here.
4. PRG = Phase Graph in the UI; mode survives only as a compatibility identifier. The per-Arc CRG is Causal Graph in compact interface copy and Causal Reasoning Graph on first educational use.
5. The room is the application; substrate is the engine. Never call the substrate "the room" or "the engine" interchangeably. Lead with the writers'-room / table-read / playable-world framing; "War Room" survives only as the legacy alias for the strategic / non-fiction mode.
6. Private and Public are first-class adjectives, not modes. "A private room" / "a public game on a hosted substrate". Not "private mode".
7. Cards are intent signals. Avoid "moves" (the substrate uses "move" loosely for the underlying action); reserve "card" for what the player actually plays.
8. Stakes are a layer, not a feature. Stakes are attached to plays, optional, opt-in. Avoid calling them "the betting feature" or "the gambling layer".
9. Don't introduce new vocabulary without adding it here. If a recurring concept shows up in two or more docs and isn't in LANGUAGE.md, it either belongs here or it's drift that should be corrected back to an existing term.
10. Console / live (ngrok tunnel) / dark (Signal) is the access language. The console is the master device (the Director's computer that holds the substrate and drives the shared screen), running an always-on Electron host that keeps the instance and tunnel up continuously — the main way a room stays on. Live, non-Directors reach the full interface over a PIN-gated ngrok tunnel — a stable, always-on public HTTPS URL (read-write; Director elevated; app-layer auth is the perimeter; Director-revocable; LAN-only fallback for fully-private tables). Dark, the async capture layer runs over Signal — the one capture channel, end-to-end encrypted (dedicated number, DMs not a group, quarantined ingress); the Director curates and commits. There is no central server (the tunnel is third-party; Signal = a normal chat; the Director machine is the always-on host). In user-facing copy don't call the console "the server"; the tunnel view is the real interface, not a "crippled mobile view." (ngrok for the always-on stable URL; Signal for sovereign/team dark capture; a Telegram bot is the separate consumer-rung surface — a trained, evolving chatbot the Director schedules to brief them (notification / query / control over the artifacts, where the compounding intelligence lives behind the chat), the B2C growth-engine channel kept distinct from team capture; Tailscale not used.)
11. Priors are human-made, never scraped. The prior-collection is humanistic by design — a person filters, structures, and sets the threads; web search only assists drafting. Don't reintroduce "automated feeds" or "scrapers" as inputs.
12. Two map types only: Graph and Board. The raw graph substrate and a board-game-style map with nested maps. Don't reintroduce "grid" or "hex" as board geometries.
13. The queue is now "Priors." "Queue" / "Driver" survive only as code/UI labels inside the Signals (Capture) surface; in prose and vocabulary it's Priors.
14. Player-archetype tag id matches its label (kebab-case) in the game-theory dashboard — no literary/code-name drift between what's stored and what's shown. New tags get an entry under Player archetypes above.
15. A decision is 1- or 2-player. Two-player = duel (a matrix); one-player = solo (a row, reality in the other seat). Don't describe game theory as inherently two-player.
16. Threads, Streams, and Positions are distinguished by the WRITE PATH, not by outcome-vs-action. All three are predictive reads over mutually-exclusive outcomes, moved by evidence; what separates them is where the read goes. A Thread is the domain's own canonical belief — canon. A Stream is one perspective's seat-owned, evidence-accruing read that stages a change to canon and terminates in a Merge. A Position is a composed forward read that never writes to canon. An action is an outcome with a known driver — when a Stream's question is one the seat itself decides, its outcomes are its candidate moves; there is no separate kind, field, or code path. Don't use "thread" for a seat's per-perspective read, or "stream" for the canonical domain belief. Retired: "Streams are action-first" — action is one framing a Stream's question may take, never its identity, and in a Public Domain it normally does not.
17. The loop is Model → Capture → Scenario. Three beats, no fourth. Review and Butterfly are retired as loop phases — don't reintroduce them; the slide-deck output lives on as Onboarding decks.
18. Scenario (capital) is the live practice / game; conviction (lowercase) is the resource. Scenario is the live practice (was "Playback"), played as the Scenario card game — scenario is a pluggable layer, so other live formats can ride the same substrate later. Scenario names the act (playing the story forward); Scenario names the practice it's played as. Don't call conviction "the betting chips".
19. The Learning layer is additive and post-hoc. Question banks, scoped practice, Curriculum, and Coverage read the domain; they never mutate force deltas. Don't frame Learning as part of generation.
20. Capture is the asynchronous practice; Scenario is the live one. Tempo is the clean split — Capture runs async (priors recorded over time, between sessions, no convening), Scenario runs live (a synchronous, high-feedback session the room plays together, acting the story forward against AI scene partners). The two modes of the Vision thesis (human judgement and vision are the edge the frontier models don't supply). Don't blur it: don't call Capture "live" or Scenario "asynchronous" at the practice level; "Playback" is retired in favour of Scenario. (The access model's live (ngrok tunnel) / dark (Signal) is a separate, device-reach layer — orthogonal to this practice-tempo split.)
21. Read / Write / Play is the player's loop; Generate is the Director's beat. Players carry only the three-beat Read → Write → Play (poker-inspired, low-friction — the onboarding surface). The fourth beat, Generate (the world simulated one step forward), plus all facilitation, is the Director's job — handle the details, keep the room social and fun. Don't burden the player-facing loop with the engine machinery; that lightness is what makes Scenario an onboarding experience.
22. Lead B2B with worldbuilding teams; the creator network is the volume tier beneath. The first buyer is the team with a real worldbuilding budget — studios, showrunners, dev execs, game/animation worldbuilders. Indie writers and creators are the downstream volume tier, reached bottom-up through the Player → Contributor → Director ladder (card game as funnel, directors as distribution) — a network that grows itself. Don't describe Meridians as a "single-player forecasting tool," a "consulting practice," or a "services-led boutique." This is the deliberate fix for the old monetization hole: worldbuilding is a real budget line; "ideation" sold to cash-poor indies was not.
23. master / client are the only sync-role words — clone and tributary are retired. The runtime type is SyncRole = "master" | "client"; use those in docs, comments, and copy. "clone" survives solely for duplicating a domain/scene (a domain clone), never for the joined origin. When you see clone/tributary for the sync role, it's drift — read it as client.
24. Director (platform account) vs director (in-instance role); Admin (platform operator) vs manager (in-instance role). Two clean splits: capital-Director = the Supabase account owner, lowercase director = the top ladder role (they're the same person, different systems). Admin = the platform operator (platform_admins / the gateway /admin); manager = the ladder role just below director. There is NO in-instance "admin" and NO platform "manager" — the words don't cross layers. (The manager role was renamed from "admin" precisely to free "admin" for the platform; don't reintroduce "admin" as a member role, and don't call the platform operator "Owner" — it's the Admin.)
25. master/client ⊥ License/Hosted — two orthogonal axes. master/client names runtime authority (who holds the record); License/Hosted names the product (where the master runs + who pays/keys). A Hosted VM is a master on our infra; a License app is a master on the user's machine; collaborators are clients in both. Don't say "hosted" to mean "client" or "master" to mean "License-only". After E1 the master is the server-of-record daemon, not the browser — the browser is the local client.