Wiki · The Colony & the Method
Architecture Overview
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 STRATIFIED PALIMPSEST is a single-application Elixir project with strict internal module boundaries. We deliberately chose a single coherent stack with zero runtime dependencies over an umbrella or polyglot design, because:
- The benchmark's core value is a deterministic, reproducible world kernel.
Zero dependencies means
mix testruns offline and a seed fully determines a trace — no hidden state from:rand, hex versions, or native sidecars. - Module namespaces (
SP.Core,SP.World,SP.Body,SP.Interface, …) give the same separation the spec's umbrella layout asks for; splitting into umbrella apps later is a mechanical packaging step (each namespace is already dependency-acyclic in the direction below).
Dependency direction (acyclic)
SP.Determinism (no deps)
▲
SP.Core.{Signal,Directive,Schema}
▲
SP.World.* ──────────────► SP.World (container)
▲ ▲
SP.Body.* (Sensor reads World) │
▲ │
SP.Genome (reads Body taxonomy) │
▲ │
SP.Interface.{,.Audit} │
▲ │
SP.Agent (contract) │
▲ │
SP.Sim ───────────────────────►┘ (orchestrator: composes World + Body + Agent + Interface)
▲
SP.Baselines.* SP.Eval SP.Observability SP.Scenario
Nothing below the Interface line may read raw world/body state across the
learner boundary; only SP.Body.Sensor (the transducer) and SP.Sim (the
runtime) touch both sides, by design — they are the Markov blanket.
The Markov blanket in code
| Blanket role | Spec term | Implementation |
|---|---|---|
| External states | world/body truth | SP.World, SP.Body structs (never crossed to learner) |
| Sensory states | signals | SP.Core.Signal produced by SP.Body.Sensor, channelised by SP.Interface |
| Active states | executed effects | SP.Core.Directive.Actuate interpreted by SP.Sim |
| Internal states | learner beliefs | the future agent's own SP.Agent state |
The learner couples ONLY through encoded observations (%{int => float}) and
opaque action channels. Verified by SP.Interface.Audit and the leakage suite.
Hybrid time
SP.Sim runs four nested timescales (see eval harness):
- microstep —
SP.World.Dynamics.step_region/1;micro_per_decisionper tick. - decision tick — metabolise → sense → decide → act.
- development tick — every
dev_intervalticks (SP.Body.Development.develop/2). - lineage — across episodes via
SP.Genomemutation/recombination +SP.Eval.
Determinism strategy
All stochasticity flows through SP.Determinism (SplitMix64), threaded as an
explicit immutable value. Regions get split sub-generators so adding a region
never perturbs another's stream. Result: identical seed ⇒ identical trace
(docs/reports/reproducibility_report.md).
Effects boundary (Jido invariant)
Agent decision logic is pure (SP.Agent.decide/3 returns {directives, state}).
It never mutates the world. Only SP.Sim interprets directives and applies
effects via SP.World.Actions. See jido_alignment.md.
sha256 be08942074e2805f — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
This page describes how one piece of software is put together. It is a map of the parts, and of the rules about which part may talk to which.
The project is a single program in a single language, with no outside libraries needed while it runs. That was chosen on purpose. With nothing external to fetch, a test run works offline, and the same starting seed produces the same run again. The parts are stacked so that dependencies point one way only, never round in a circle.
A boundary runs through the middle of the design. On one side sit the world and the body. On the other sits the learner. The learner does not read the world directly. It only receives encoded observations, and sends actions back through channels that carry no meaning of their own.
The page also sets out four nested clocks, from the smallest tick of physics up to whole lineages, and says where every piece of randomness is allowed to come from. It is an account of a design, not a report of a result.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is be08942074e2805f
Clear — written for this website, not the source document
This document is an architecture overview: an account of how the codebase is arranged, and why, rather than a report of anything it has achieved.
It opens with the choice that shapes everything else. The project is one application in one language, with strict boundaries between modules and no outside dependencies while it runs. Two reasons are given. First, the value of the work lies in a world kernel that behaves the same way twice, so a test run must work offline and a seed must fully determine a trace, with no hidden state creeping in. Second, module namespaces already give the separation that a multi-application layout would give, so splitting things apart later would be mechanical packaging work rather than redesign.
Next comes the dependency direction, drawn as a stack whose arrows point one way. Below the interface line, nothing may read raw world or body state across the learner boundary. Only the sensor, which turns world state into signals, and the runtime, which carries out effects, touch both sides. The document says plainly that those two are the boundary, and that they touch both sides by design.
A short table maps the roles of that boundary onto real code. External states are the world and body structures, which are never crossed to the learner. Sensory states are the signals the sensor produces. Active states are the effects the runtime carries out, and internal states belong to the learner alone. The learner couples only through encoded observations and opaque action channels, and a separate audit plus a leakage suite is named as the thing that checks this.
Two further sections follow. One describes four nested timescales, from the smallest physical step, through a decision tick, to a slower developmental tick, and finally to lineages across episodes. The other says that all randomness flows through a single generator threaded through the program as a plain value, with regions given split sub-streams so that adding a region never disturbs another's sequence.
The page closes on an effects boundary: the agent's decision logic is pure and returns instructions only, and just one component interprets those and changes the world.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is be08942074e2805f