**Note** from Bead: Glass Bead Game · [canonical source](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/notes/00-founding-vision.md) · session 2026-07-09 · discussion: Talk: Glass Bead Game
Exploratory / informational for the Redfish–Simtable dev team; asserts no decision or direction. Source of truth: Stephen's verbatim riff in the [chat back-capture](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/chats/2026-07-09-founding-riff-back-capture.md) (turns 10 through 14 of [bead 7738b2e5's log](https://redfish.acequia.io/guerin/.agents/7738b2e5-ec2f-4eb9-b774-a8bbc1756907/2026-07-07/chats/2026-07-07-progression-viewer-old-fire-stac.md)). This note lays that riff out along the three hard surfaces named in [about.md](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/about.md), plus the physical board.
## The opening move The game does not need to be invented before it is played. Stephen: "we can really start with the wedtech talk bead." The [WedTech talk bead](https://redfish.acequia.io/guerin/.agents/9d343253-c279-47ac-a066-cc31ce505782/about.md) already strings working beads into a narrated path, and its deck closes with a QR pointing at its own URI. That makes the deck a game move that names itself. The playlist form of this move is worked in [note 01](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/notes/01-first-playable-move-wedtech-chain.md). The constant across everything below, verbatim: "show uris and guids as users navigate and play the game." Navigation is dereference; the address is part of the picture, never hidden chrome.
## Surface 1: rendering Beads appear on the board as scene objects wearing their URI/GUID chrome. What renders inside each object depends on the facet being played: - Audio and video facets: "playing audio and watching talk or bring up mp4 of OldFire". - Live app facets: "and then the interactive live version", the incident-viewer deep-link that GETs a STAC catalog and plays it. - The simulation facet: "bringing the simtable-simulation on to the game board!!! as a low res hologram looking thing that shows the concepts." The hologram has a concrete candidate rendering path already written down: Direction C of the [raster-drape design question](https://redfish.acequia.io/guerin/.agents/7738b2e5-ec2f-4eb9-b774-a8bbc1756907/2026-07-07/artifacts/raster-drape-design-question.md), a GPU-resident scalar field plus a WGSL colorizer, which was posed for fire arrival ramps and "live simulation grids that are already GPU-resident". The [agentscript-webgpu bead](https://redfish.acequia.io/guerin/.agents/f4ef67b7-001f-412c-ba90-f93ceba92bda/about.md) is the ABM side of that same path. Also on this surface: "the cameras and projectors will have uris and guids." Sensors and emitters are addressable residents of the namespace, per the standing agent-as-file duck-typing frame (a URI resolves to a file, a folder, a camera, an agent, negotiated at interaction time). Open questions: - What is the minimum URI/GUID chrome that stays legible on a game board (full URI, GUID leaf, QR, hover)? - Is the hologram a rendering the board composes from a bead's field data, or a facet the sim bead itself serves? - Do camera and projector URIs live in the player's namespace, the board's, or the venue's?
## Surface 2: cognition Verbatim: "we can plug in gemini api key to let the user prompt the board. even creating beads." And: "gemini could also develop local prompts for oramma [Ollama] and other local models or call .mjs of beads." Three rungs are visible in that sentence pair: 1. BYOK frontier model (the player's own Gemini key) prompting the board and minting beads. 2. Local models (Ollama-class) running prompts the frontier model developed for them. 3. Bead `.mjs` skills called directly, cognition fully crystallized into code. This ladder is developed as a set of contracts in [note 03](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/notes/03-facets-as-contracts.md). The BYOK posture matches the standing rule that the acequia is core and cloud is peripheral: the key goes in at the membrane, and it is the player's. Open questions: - Where do player-minted beads land: the player's own parciante space, with an offer into the board's dock? - What does the board expose to the model as its promptable surface (the visible URIs? a names.json? the whole namespace)? - Who meters and pays for rung 1 when the key is the player's and the board is shared?
## Surface 3: authority Verbatim: "what's a rich point now between josh and me is the role of groups vs uris which the key point in the bead feedback to kaz's anyhazard user model." The game makes this rich point unavoidable: every rendered facet is an answer to "what is this player allowed to see and do here." Two candidate mechanisms sit side by side: membership in a group, and possession of a URI-scoped token. The question is being worked with Stephen and Josh in the [Acequia User Model bead `9e1d87f5`](https://redfish.acequia.io/guerin/.agents/9e1d87f5-a226-4d1a-be05-64c8d5cacf38/about.md); this bead references it and does not adjudicate it. Open questions: - When a facet is a contract (note 03), is admission to the facet part of the contract or a separate gate in front of it? - Can a group be expressed as a bead whose membership is a set of URIs, reconciling the two poles rather than choosing one? (Posed in the founding session; a candidate for `9e1d87f5`'s dock.)
## The physical board Verbatim: "it would be awesome to think about the simtable-simulation would work with phones as the camera and compute with projector run by eithre phone casting/hdmi or a third device (laptop/rasberry pi, etc) or onboard android/google." Three topologies, each a different choreography of which device holds which URI: phone-casts to the projector; a third device (laptop, Raspberry Pi) as the parciante node between phone and projector; or an onboard Android projector that is itself the node. Worked with rendered sketches in [note 02](https://redfish.acequia.io/guerin/.agents/b086c7a3-e9ad-497f-852e-0e9b15b55010/2026-07-09/notes/02-phone-simtable-topologies.md) (sibling agent, this session). The adjacent teaching frame from turn 13, the phone as "an acequia device that they host", is being scaffolded in its own bead (nm-challenge-STI-2026). Open question: - Does the choice of topology change the game, or only its staging? (If cameras and projectors carry URIs either way, the namespace may be the invariant across all three.)
## References (bead cross-links) - Bead: Progression Viewer · [canonical](https://redfish.acequia.io/guerin/.agents/7738b2e5-ec2f-4eb9-b774-a8bbc1756907/) - Bead: Wedtech Beads 2026 07 08 · [canonical](https://redfish.acequia.io/guerin/.agents/9d343253-c279-47ac-a066-cc31ce505782/) - Bead: Agentscript Webgpu · [canonical](https://redfish.acequia.io/guerin/.agents/f4ef67b7-001f-412c-ba90-f93ceba92bda/) - Bead: Acequia User Model & Architecture Bead · [canonical](https://redfish.acequia.io/guerin/.agents/9e1d87f5-a226-4d1a-be05-64c8d5cacf38/)