Wiki · The Colony & the Method
The Overlooker UI (Phoenix LiveView)
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 overlooker is a third-party, omniscient, real-time view of the whole world at every tick, with a Markov-blanket monitor that proves — per tick, with an independently re-derived verdict — that the agent receives only the opaque observation and lives entirely outside the world.
It is an isolated Phoenix app under ui/. The pure stratified_palimpsest
core stays zero-dependency; the UI consumes it as a path dependency and only ever
reads world state and the evidence log. It never feeds the agent.
Run it
cd ui
mix deps.get # the only place in the repo that fetches hex deps
mix phx.server # then open http://localhost:4000 (PORT env to change)
For headless verification of the UI logic (no browser, used in CI):
cd ui && mix test # mounts the LiveView, steps it, asserts the verdict;
# loads a tampered replay and asserts the badge turns RED
Note: the LiveView render/interaction pipeline is fully test-verified (
ui/test/sp_ui_web/overlooker_live_test.exs). Binding a live TCP port viamix phx.serveris standard Phoenix infra and is the intended manual run.
What you see
Three stacked panels:
- Markov-blanket monitor — three columns drawn as WORLD (external states) |
BODY/BLANKET (afferent signals + efferent actions) | AGENT (outside the world,
fed ONLY the opaque
channel=valueobservation). A large verdict badge — green BLANKET INTACT or red BLANKET VIOLATION — is recomputed every tick bySP.Sim.Verifier, itemising the four checks (structural, token scan, morphology provenance, encode-equivalence). The verdict is re-derived, never trusted from an engine flag. - Overlooker (god view) — for every region, heatmap grids of each layer: L0 (nutrient, temperature, solvent, toxin), L2 (cavity, strain), L3 (3 spectral bands). The body's cell is outlined. Materials / infrastructure / ecology counts, seam readiness, and the region/seam graph are shown.
- Signal & action audit — the per-tick afferent signals (with their data) and efferent decoded actions (with gated/ungated/decode-error status).
Controls
- play / pause / step / reset, and a speed selector.
- Live config: seed, baseline agent, and horizon — applies a fresh live run.
- Replay: pick a recorded
runs/*.jsonlevidence log to scrub through.
Live vs replay
- Live steps the real
SP.Simone tick at a time (recording an observer frame each step) — "the world as it is at all times". The frame is the same one the evidence recorder produces, so what you watch is exactly what gets verified. - Replay streams a recorded JSONL evidence log (produced by
scripts/record_run.exs), rebuilding the channel map from the seed and recomputing the verdict for each frame.
Architectural notes
- The AGENT column's content derives solely from
frame.afferent.observation; the god-view panels read world state. This separation mirrors the runtime boundary and is asserted by the LiveView tests. - Live stepping happens inside the LiveView process (a timer-driven
:tick); a sharedRunner+Phoenix.PubSubfan-out for multiple simultaneous viewers is a straightforward extension (seedocs/limitations.md). - The client uses the vendored Phoenix / LiveView UMD JS served directly from the deps (no bundler/build step).
sha256 5401c3f7750ae484 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
This page describes a viewing interface: an outside, all-seeing, live view of the whole world at every tick, with a monitor that re-derives, tick by tick, whether the agent received only the opaque observation.
It is a separate application, kept apart on purpose. The core stays free of dependencies; the interface reads world state and recorded logs and never feeds the agent anything.
Three stacked panels are described. A boundary monitor with a large verdict badge, itemising four checks. Its verdict is re-derived each tick rather than trusted from a flag the engine set. A god view with heat maps of each layer per region, the body's cell outlined, and the graph of regions and seams. And an audit of the signals coming in and the actions going out, each marked as decoded, gated or in error.
The controls allow play, pause, step and reset, a live run with chosen settings, or scrubbing through a recorded log.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 5401c3f7750ae484
Clear — written for this website, not the source document
This document describes an observer interface built as a separate application, and it is careful about the separation. The core of the project stays free of fetched dependencies; the interface consumes it as a local dependency, only ever reads world state and recorded evidence logs, and never feeds the agent.
What it offers is an outside, all-seeing view of the whole world at every tick, together with a monitor for the boundary around the agent. That monitor's verdict is re-derived on every tick rather than taken from a flag the engine set, which is the distinction the page keeps returning to.
Instructions for running it are given, including a headless mode used for automated checking that mounts the interface, steps it, asserts the verdict, then loads a deliberately tampered replay and asserts the badge turns red. A note explains which part is covered by tests and which part is ordinary manual running.
Three stacked panels are described. The first is the boundary monitor, drawn as three columns for the world, the body and its boundary, and the agent, which sits outside the world and is fed only the opaque channel-and-value observation. A large badge shows whether the boundary held, itemising four checks. They cover structure, and a scan for meaningful tokens. They cover whether every observed channel could have come from the organs the body actually had, and whether the observation is exactly the channelisation of the recorded signals. The second panel is the god view: per-region heat maps for each layer of the world, the body's own cell outlined, counts of materials, structures and organisms, readiness for expansion, and the graph of regions and seams. The third is an audit of the incoming signals with their data and the outgoing decoded actions with their status.
Controls allow playing, pausing, stepping and resetting at a chosen speed, configuring a fresh live run by seed, strategy and horizon, or picking a recorded log to scrub through.
A section contrasts the two modes. Live stepping advances the real simulation one tick at a time and records the same frame the evidence recorder produces, so what you watch is exactly what gets checked. Replay streams a recorded log, rebuilding the channel mapping from the seed and recomputing the verdict for each frame.
The closing notes make the architectural point explicit: the agent column's content comes solely from the recorded observation while the god-view panels read world state, mirroring the runtime boundary, and this separation is asserted by the interface's own tests. A limitation is named plainly, that stepping happens inside the viewing process and a shared runner for several simultaneous viewers would be a straightforward extension.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 5401c3f7750ae484