Wiki · The Colony & the Method
Production Deployment Guide
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.
Build artifacts
The pure core has no hex dependencies, so there is nothing to vendor or fetch. Two deployment shapes are supported:
1. Library / embedded
Add this app as a path or git dependency and call SP.Sim / SP.Scenario
directly from your harness. The learner couples only through SP.Interface
(encoded observations + opaque action channels) and the SP.Agent behaviour.
2. Container
docker build --target test -t sp:test . # runs the QA suite during build
docker build --target runtime -t sp:run . # operator image
docker run --rm sp:run # default: baseline benchmark
docker run --rm sp:run run scripts/evidence.exs # any mix entrypoint
The Dockerfile uses elixir:1.18-otp-27-alpine. MIX_ENV=prod for the runtime
stage; the test stage runs mix test.
Configuration & provenance
- Scenarios live in
config/scenarios/*.json; seed sets inconfig/seeds.json. - Always capture
SP.Observability.provenance/1alongside any run — it records the seed, cadence, world dims, and the observation catalogue version, which together reproduce the run exactly. - The observation/action schema is versioned (
SP.Interface.catalogue_version/0). Bump it if you change the catalogue, and regenerate golden artifacts.
Serving a future learner safely
- Run the agent against
SP.Interface-encoded observations only. - Never expose
SP.Interface.reveal_*,SP.Baselines.Lens, or rawSP.World/SP.Bodystructs to the learner process. - Keep
debug?: falsefor serving; enable it only for validation. - Pin the channel-map seed per scenario for reproducibility; vary it across scenarios so channel ids cannot be memorised across worlds.
Scaling
Episodes are pure functions; run them concurrently with Task.async_stream
across seeds/agents (no shared mutable state). For the live Jido runtime, each
agent/probe is a supervised process — see jido_alignment.
Upgrades / migration
- Dynamics or interface changes → regenerate
config/golden/and review the diff (CI guards against accidental drift). - Adding a sensor/action → update
SP.Body.Sensor/SP.Bodygating ANDSP.Interfacecatalogues together, bumpcatalogue_version, extend the signal/action catalog docs and tests.
sha256 a71697697eaf3a04 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
This is a short deployment guide. It describes two ways to run the software, how to capture enough information to reproduce a run, and how to serve a future learner without letting it cheat.
The two shapes are simple. Either add the project as a dependency and call it directly from your own harness, or build a container, where one build target runs the test suite and another produces an operator image.
The part worth reading twice is the section on serving a learner safely. It says to hand the learner only encoded observations, and never to expose the functions that reveal what things mean. Keep the debugging mode off when serving, and fix the channel mapping within a scenario while varying it between scenarios, so that channel identities cannot be memorised.
A short section on scaling notes that episodes are pure functions, so they can be run side by side without shared state.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is a71697697eaf3a04
Clear — written for this website, not the source document
This is a deployment guide for a benchmark environment, and it is short because the software has no external dependencies to fetch.
Two deployment shapes are described. In the first, the project is added as a dependency and called directly from your own harness, with the learner coupling only through the interface and the agent contract. In the second, a container is built, with one target that runs the quality suite during the build and another that produces an operator image.
A configuration section explains where scenarios and seed sets live, and asks that a provenance record be captured alongside any run. That record holds the seed, the cadence, the world dimensions and the version of the observation catalogue, which together are what make a run reproducible. The guide says to bump that version whenever the catalogue changes and to regenerate the stored artifacts.
The most important section is about serving a future learner safely, and it is a numbered list of four rules. Run the agent against encoded observations only. Never expose the functions that reveal meanings, the debug lens, or the raw world and body structures to the learner's process. Keep the debug mode off when serving, and enable it only for validation. And fix the channel mapping within a scenario for reproducibility, while varying it across scenarios so that channel identities cannot be memorised.
A scaling note says episodes are pure functions with no shared mutable state, so many can run side by side across seeds and agents.
A final section on upgrades says that any change to the dynamics or the interface means regenerating the stored artifacts and reviewing the difference. Adding a sense or an action means updating the sensing, the gating and the catalogues together, bumping the version, and extending the catalogue documents and tests.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is a71697697eaf3a04