Wiki · The Colony & the Method
Door lifecycle — the full sequence diagrams (2026-07-14)
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.
The complete message-flow of the door system: boot, one-key open, graceful close, the journey, go-live, and — because receipts beat rhetoric — the two spawn-storm incidents and the breakers that make their whole class structurally impossible now. Live counterpart: the living map on
http://127.0.0.1:8090/door(renders these same actors from/api/door/state+/api/door/journeyevery 3s). Gaia projects the underlying register + journey files verbatim (studio.doors.register,studio.doors.journey).
1. Logon / boot — how the door and witness return with zero clicks
sequenceDiagram
participant W as Windows logon
participant V1 as UNI-Door-Watchdog.vbs (Startup)
participant V2 as UNI-Door-AutoOpen.vbs (Startup)
participant V3 as UNI-Gaia-Watchdog.vbs (Startup)
participant DW as door_watchdog.ps1
participant L as launcher.cjs (:8090)
participant GW as gaia_watchdog.ps1
participant G as gaia_server.cjs (:8096)
participant C as Chrome
W->>V1: fire (once per logon)
W->>V2: fire (once per logon)
W->>V3: fire (once per logon)
V1->>DW: start hidden (named mutex UNI_DOOR_WATCHDOG - duplicates exit)
DW->>L: start if down, re-check every 5s forever
V3->>GW: start hidden
GW->>G: start server + capture_minds_loop, re-check every 5s forever
V2->>V2: wait up to 90s for :8090
V2->>C: open the door window ONCE (never re-opens a window you closed)
Note over DW,G: door_boot_proof.ps1 / gaia_boot_proof.ps1 flip the<br/>boot-persistent gates to PASS after a REAL reboot - never before.
2. ONE KEY — opening the studio (always a deliberate click)
sequenceDiagram
actor O as Operator
participant D as /door page
participant L as launcher.cjs
participant DL as door_lifecycle.cjs
participant SU as studio_up.ps1
participant M as OS mutex UNI_STUDIO_UP
participant S as OBS + MediaMTX + console + overlays + publisher
O->>D: click "ONE KEY - OPEN ALL"
D->>L: POST /api/door/open {door:all} (loopback + x-uni-cc)
L->>DL: verb(all, open)
DL->>DL: append ledger entry (actor, method, prediction)
DL->>SU: spawn (non-detached, output to logs/door_lifecycle.out.log)
SU->>M: WaitOne(0)
alt mutex HELD (first instance)
SU->>SU: clear OBS .sentinel + safe-mode markers (self-heal FIRST)
SU->>S: start each service (idempotent reuse), verify ports
SU->>SU: overlay proof gate (verify_overlays exit 0)
SU->>SU: open command-center window ONLY if none exists (window dedup)
else mutex BUSY (any extra instance)
SU-->>DL: exits in <1s having started NOTHING
end
Note over D: journey verify step OBSERVES the doors opening<br/>and completes itself - it never spawns anything.
3. Graceful close — the shutdown button
sequenceDiagram
actor O as Operator
participant D as /door page
participant L as launcher.cjs
participant SU as studio_up.ps1 -Stop
participant ST as systray_watchdog
participant N as console/overlays/publisher (/shutdown verbs)
participant OBS as OBS
O->>D: click "CLOSE ALL (graceful)"
D->>L: POST /api/door/close {door:all}
L->>SU: spawn -Stop
SU->>SU: live-guard - REFUSES if MediaMTX path uni is INGESTING (you are on air)
SU->>ST: stop systray FIRST (nothing resurrects mid-close)
SU->>N: POST graceful /shutdown to each (flush + exit 0)
SU->>OBS: CloseMainWindow -> taskkill WM_CLOSE -> force only as fallback
SU->>SU: second sweep + VERIFYING TEARDOWN -> "DOWN: VERIFIED CLEAN"
Note over SU: The frame (door), the witness (Gaia) and every REMOTE door<br/>are untouched - colony held HTTP 200 through the entire drill.
4. The journey — reboot-surviving vectors (reads never actuate)
sequenceDiagram
actor O as Operator
participant D as /door page (3s poll)
participant J as door_journey.cjs (state on disk)
participant OS as Windows
Note over J: studio_ready -> feature_test -> go_live -> run_of_show -> off_air<br/>(the two-reboot ceremony was RETIRED 2026-07-15; reboot is runtime STATE, not a step)
D->>J: GET /api/door/journey (pure read)
J->>J: arm current step SYNCHRONOUSLY (un-interleavable - the race fix)
J->>OS: measure (ports+spool for studio_ready, broadcast_test.go, streaming, on-air clock)
J-->>D: step status + honest live detail
O->>OS: type CONFIRM + GO LIVE in the console (G-PA) — the journey can only WATCH for it
OS-->>J: streaming==true -> go_live completes; sawLive + liveStartedAt PERSISTED (2026-07-17)
Note over J: run_of_show measures the on-air clock vs the slot duration;<br/>off_air completes when streaming stops after sawLive (survives a mid-show restart)
Note over D,J: LAW (burned in 2026-07-14): a polled READ never spawns anything.<br/>Every actuation is a deliberate operator click or an explicit verb.
5. Go-live — the key that stays human
sequenceDiagram
actor O as Operator (Organic Operator Michael Polzin)
participant CC as command center :8098
participant OBS as OBS
participant MTX as MediaMTX :1935/uni
participant F as fan-out (restream.ps1 / endpoints panel ffmpeg)
participant P as YouTube / Twitch / up to 20 endpoints
O->>CC: type CONFIRM + GO LIVE (G-PA - no agent can ever do this)
CC->>OBS: SetStreamServiceSettings rtmp://127.0.0.1:1935 key uni + StartStream
OBS->>MTX: ONE encode
F->>MTX: read path uni
F->>P: ffmpeg -c copy per endpoint (keys from operator shell / encrypted store - never git)
Note over CC: OFF AIR is 1-click, never blocked.<br/>The colony scene carries the honest gate ticker:<br/>forage-pureworld-graduation stays disclosed, never claimed.
Appendix — the two spawn storms and their breakers (honest incident record)
sequenceDiagram
participant T as /door tabs (3s polls)
participant J as journey verify (OLD, buggy)
participant SU as studio_up (xN, stacking)
participant OBS as OBS + cc windows (xN)
Note over T,OBS: STORM (2026-07-14): the verify step auto-triggered ONE KEY,<br/>and the race fix discarded its once-only guard -> every 3s poll spawned<br/>studio_up -> OBS + a NEW command-center window. Dozens stacked.
T->>J: GET journey (every 3s, every tab)
J->>SU: doors.verb(all, open) [BUG: side-effect in a read]
SU->>OBS: start OBS + pop cc window (8b was unconditional)
Note over T,OBS: BREAKERS NOW (three independent layers):<br/>1. reads never actuate - verify steps are pure observers (d09f700)<br/>2. one bring-up at a time - OS mutex UNI_STUDIO_UP inside studio_up itself<br/>3. idempotent windows - cc window opens only if none exists for its profile<br/>Any one alone stops the storm; all three are in.
Receipts: docs/receipts/stability_audit_2026-07-14.md (Class A drill outputs) ·
gate rows door-lifecycle-circle, door-boot-persistent, door-storm-breakers in evidence/gates.ndjson.
sha256 0b473965a413bdbe — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
Sequence diagrams, one after another, draw the messages that pass between the parts of a studio control system. They cover how it comes back after a restart with no clicks, what happens when the operator presses the single open-everything button, how a graceful shutdown runs, how the journey through a broadcast is tracked, and how going live works.
The last diagram is the one that gives the page its character. It is an incident record. Twice, a background page refresh accidentally triggered the open-everything action, so every few seconds a new copy of the studio started, and windows stacked up. The page draws the failure honestly and then draws the three independent guards now in place, noting that any one of them alone would stop it.
One rule runs through the whole page: a routine read never causes anything to happen. Actions only follow a deliberate click. Going off air is the exception in the other direction — one click, and never blocked.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 0b473965a413bdbe
Clear — written for this website, not the source document
This document is drawn rather than written. It is a series of sequence diagrams showing the exact message flow through a studio control system, with short notes between them. A live page renders the same actors from the running system, so the diagrams have a counterpart you can watch.
The first diagram covers logon. Three small startup scripts fire once per logon, each starting a supervisor that keeps its service running and re-checks forever. One of them waits for the control service to answer before opening the operator's window exactly once, and the note is careful to say it never re-opens a window you deliberately closed. A further note says the gates that claim boot persistence flip only after a real restart, and never before.
The second diagram is the single open-everything action. The operator clicks; the request goes to the control service, which appends an entry to a list that is never edited, naming the actor, the method and the prediction, and then spawns the bring-up script. That script takes an operating-system lock. If it holds the lock it heals a few known bad states first, then starts each service in a way that is safe to repeat. It checks the ports, runs a proof step over the overlays, and opens a window only if none already exists. If the lock is held by someone else, the extra copy exits immediately having started nothing.
The third diagram is the graceful close. It refuses outright if the system is currently sending a live stream. Then it stops the thing most likely to restart something, asks each service to shut down cleanly, closes the broadcast application politely before ever forcing it, and sweeps a second time to verify the teardown. A note records that the frame, the witness and every remote door were untouched, and that the colony stayed answering throughout.
The fourth diagram is the journey: a sequence of named steps from studio-ready through going live to off-air, held on disk so it survives a restart. A polled read measures the world and reports honest detail, and a note states the law burned in after an incident: a read never causes anything to happen.
The fifth is going live, and its point is that the final key stays human. The operator types a confirmation in the console, and the document says no agent can ever do this. Going off air is one click and is never refused.
The appendix is the incident record. A verify step used to trigger the open-everything action as a side effect of being read. A later change removed the guard that had made it happen only once, so every poll from every open tab started another copy and dozens stacked. Three independent breakers are now in place, and the page says any one alone would have stopped it. The files recording what was run, and the gate rows, are named at the end.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 0b473965a413bdbe