Wiki · The Colony & the Method
Master prompt for the next agent (paste into a fresh chat)
[redacted: category] — 1 private address, 3 operator path. Nothing else was altered. The document is otherwise exactly as it is written in the repository, and the sha256 below is of the original, so what was ingested stays checkable.How to read this page
Three ways to read this page. Precise is the document itself, exactly as it is written in the repository. Plain and Clear were written for this website to help you meet that document — they are about it. They are not it, and they are not evidence.
Eighty-four pages about the colony. Each agent is an Elixir process holding a generative model and doing inference, attached to a body that logs into a Minecraft world as an ordinary player. Around that sit the broadcast suite that films them and the runbooks that keep the whole thing running. There are typed specifications for each organ of the model, plus the world and genome specs. There are also the adversarial review personas used to attack a proposed change before it ships.
It is for the reader curious how a running system is put together and how it is held to account. The accountability half is the more distinctive. There is a lab protocol governing evidence and attribution, and a claim fence that restricts the vocabulary a claim is allowed to use. There is a public gate log. And there is a standing invitation to reproduce any verdict from the commit and the seed named in its receipt.
Start with the public read, then the lab protocol, then the falsification invitation. If you want the mathematics rather than the operations, go straight to the typed organ specs.
What it is not: a description of a mind, and not all one kind of document. A large part of this corpus is design and planning — specs marked as proposed rather than applied, organs designed but not built, plans that were later superseded — and each page states which it is. A specification is not a running system, and these pages are careful about the difference; the reader should be too. Eight documents were withheld from publication because they describe private infrastructure.
Your browser cannot switch reading levels, so the document itself is shown.
Precise — the source document
This is the document. Rendered from the repository at the commit above, with nothing rewritten for the web. A gate re-renders it on every deploy and fails the build if a single byte differs.
Paste the block below into a new agent chat. Then share the additional repos (the YouTube video library repo(s) and content/film repos) when it asks. It will refine and expand the plan against everything it can see and write the result back into the Strings repo.
You are taking over the design and build of the UNI Production Platform — a full, end-to-end, broadcast-grade LIVE production system for the EducateWright nonprofit and the UNI project. A working foundation already exists; your job is to ingest the related repos (especially a VAST existing YouTube video library and content/film repos the operator will share) and expand a saved plan into a complete, buildable, containerized-on-UNI.OS design — then start building it.
READ FIRST, in this order:
[redacted: operator-path]\Documents\Strings\docs\UNI_PRODUCTION_PLATFORM.md— the grounding plan. Read it fully.[redacted: operator-path]\Documents\Strings\viewer\director_show.cjs,obs_stage.cjs,launch_channels.ps1,obs_inventory.cjs— the PROVEN production foundation (an external Director cues a set-once OBS vision-mixer; OBS passes ONE feed to YouTube).- The Claude memory note ops_multifeed_broadcast — the architecture + the hard-won dual-GPU/WGC/CEF rendering lessons.
[redacted: operator-path]\Documents\UNI.OS\services\glass\(the REAL/glasscockpit),services/control_mcp\(the appliance MCP + approval gate), anddocs/plans/GLASS_COCKPIT_AND_APPROVAL.md.
ESTABLISHED FOUNDATION (build on it; do not relitigate):
- The Director model: ONE external show-runner cues a set-once vision-mixer; the encoder passes ONE feed. Never pile sources into the encoder.
- On the Windows dev box, WebGL renders black in OBS CEF + cross-origin iframes; only real Chrome windows captured via WGC work. This is a dev-box artifact and goes away once containerized on UNI.OS/Linux — design for the container target, not the dev box.
- The real glass cockpit =
https://[redacted: private-address]/glass/(NOT the:8080builder). - The Minecraft colony production (Strings:
viewer/director.js/SP.Producer/:3020) is self-contained — it is ONE source; leave it alone.
THE GOAL: a 7-day-a-week live broadcast, 4 hours × 3/day to cover all time zones, multilingual, at CNN/BBC/PBS/Twitch quality, run by ONE operator + guests + the UNI expert (AI) with a full LLM/MCP-backed production team. It must run as containers in UNI.OS (move the entire pipeline off the dev box). Mission: the science feed for UNI + EducateWright — end school shootings, solve trauma, align mental-health treatment to nature, world peace, global understanding, free food/water/health, and a path to travel the stars.
REQUIRED CAPABILITIES (expand each into a buildable, containerized design):
- A containerized vision mixer/compositor on UNI.OS → ONE program → RTMP/SRT → YouTube (+ restream to Twitch/others).
- The UNI Producer: an LLM/MCP-driven show-runner that owns the run-of-show, cues cuts, controls music volume + auto-ducking under speech, writes & speaks narration (multilingual TTS), manages guests, and obeys the operator's voice OR text commands (the one-man-band pedalboard).
- An MCP production extension so any LLM can drive the whole show (
cut_to,set_music_volume,duck,narrate(text,lang),admit_guest,roll_clip,set_overlay,start_segment,schedule, …), with destructive ops human-approval-gated. - Sources: operator webcam(s)+mic, the colony cam,
/glass, graphics overlays, and pre-recorded content from the existing YouTube library. - Remote guests: a simple UNI.OS-hosted website where a guest connects cam+mic, authenticates, lands in a green room, and the host admits them to air (WebRTC; talking-head + panel layouts; multiple guests).
- A broadcast graphics package: lower-thirds, tickers, full-screen titles, bumpers, multilingual captions/subtitles, brand, clocks, ON AIR.
- A scheduler/playout for 24/7 resilience with fallback content from the YT library.
- Multilingual captions + narration.
WHAT YOU MUST DO:
- Ingest the repos the operator shares — the YouTube video library repo(s), the content/film repos — plus UNI.OS, uni-mind, and Strings. Map what content exists and how it is produced.
- Refine/expand
docs/UNI_PRODUCTION_PLATFORM.mdinto a complete, buildable design: pick the containerized mixer tech, the WebRTC stack, the MCP tool surface, the graphics framework, the TTS/caption stack, the scheduler, and the restreamer — justify each choice. - Produce: Podman quadlet container specs for UNI.OS, the MCP extension spec, run-of-show templates + a run-of-show guide, the guest-join app design, the operator control UI (voice + text), and a phased build roadmap.
- Save everything back into the Strings repo (
docs/+ a newproduction/tree), grounded in the proven foundation.
CONSTRAINTS: free/open tooling; containerized on UNI.OS (rootful Podman, quadlets, uni-lab MCP with human-approval-gated mutations — you cannot self-approve); honesty (timestamp + source every status claim); do not stress the dev box. Keep ONE operator + guests + the UNI expert able to run a CNN/BBC/PBS-par show by voice or text.
sha256 daf0b9a22c77f6b1 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
This page is a prompt to paste into a fresh session, handing over the design and build of a live production platform. It is written to be read by an assistant rather than by a person.
It sets a reading order, then lists what it calls the established foundation and asks that it not be relitigated. One item there is unusually honest: a rendering problem is named as an artifact of the current development machine, with an instruction to design for the container target rather than around a temporary quirk.
The goal is stated at full ambition, including a broadcast schedule, several languages, a quality bar named by comparison, and a mission statement far larger than any of the engineering.
Required capabilities follow as a list to expand into buildable designs, then four numbered tasks, then constraints. Free tooling, containers, honesty with a timestamp and a source on every status claim, and an approval gate the agent cannot pass on its own.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is daf0b9a22c77f6b1
Clear — written for this website, not the source document
This page is a handover prompt, meant to be pasted into a fresh session so that another agent can take over the design and build of a live production platform. It is addressed to that agent rather than to a reader, which gives it an unusual voice.
It opens with a short instruction to the operator about which further repositories to share once the agent asks, and says the agent will refine the plan against everything it can see and write the result back.
The prompt then sets a reading order of four items. A grounding plan to read fully, and several existing scripts described as the proven production foundation. A memory note carrying the architecture and some hard-won rendering lessons, and the real cockpit service with its approval gate.
A section headed as the established foundation asks that these points not be relitigated. The first is an architectural pattern: one external show-runner cues a mixer that is set up once, and the encoder passes a single feed, with an explicit instruction never to pile sources into the encoder. The second is the most interesting, because it is a correction of a natural mistake. A rendering failure on the current development machine is named as an artifact of that machine, and the agent is told to design for the container target rather than around a temporary quirk. The third corrects which surface is the real cockpit. The fourth says the existing colony production is self-contained, is one source, and should be left alone.
The goal is stated at full ambition. A broadcast every day of the week, in several sessions to cover time zones, and in several languages. A quality bar named by comparison with established broadcasters, run by one operator plus guests and an assistant, with everything running as containers rather than on the development machine. The mission sentence that follows is far larger than any of the engineering around it, and the page states it plainly rather than hedging it.
A list of required capabilities follows, each to be expanded into a buildable containerized design. There is a mixer producing one programme, and a show-runner that owns the running order and can cut, control music and speak narration in several languages. There is a tool surface so any assistant can drive the show, with destructive operations gated behind a human. And there is a set of sources, a route for remote guests through a green room, a graphics package, a scheduler with fallback content, and captions.
Four numbered tasks say what the agent must actually do. Ingest the shared repositories and map what content exists. Expand the grounding plan into a complete design, with each technology choice justified. Produce a named set of artifacts including container specifications and a phased roadmap, and save all of it back into the repository.
The constraints close the page. Free and open tooling, and containers with human-approved mutations that the agent cannot approve for itself. Honesty in the form of a timestamp and a source on every status claim, and an instruction not to stress the development machine.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is daf0b9a22c77f6b1