Wiki · The Colony & the Method
Genome, Development, and Evolution
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.
Hereditary substrate (SP.Genome)
A genome is a prior structure that parameterises morphogenesis — explicitly not a symbolic rulebook for the world (Hard constraint #1). Fields:
growth_plan— ordered list of organs the body attempts to grow.maturation_rate— how fast organs ripen (0.05..0.5).thrift— a metabolic-bias prior (0..1).lineage,generation,parents— lineage bookkeeping.
Developmental grammar (SP.Body.Development)
Development consumes a growth budget that accrues only from energy surplus
(SP.Body.metabolize/2). Each developmental tick (develop/2):
- Maturation — immature organs ripen by
maturation_rate(small budget cost). - Growth — if budget allows, grow the next plan organ whose prerequisites are
already mature, attached to its deepest prerequisite part (
SP.Body.grow/4).
Stage (stage_of/1, 0–4) is derived from the deepest organ tier present.
Because growth uses SP.Body.grow/4 (which checks prerequisites and parentage),
development can never produce an impossible body graph (Invariant #9, property
test in SP.Body.DevelopmentTest).
Phenotype constraints / viability selection
- Each mature organ adds metabolic upkeep (
0.025 + 0.005·n_organs), so morphology is never free — a body must forage well enough to fund its complexity (SP.Body.step/2). - Selection is through the world itself: viability (
SP.Body.Viability) is an envelope + preferred-state prior + risk, evaluated only by the eval harness. There is no fitness scalar handed to the agent.
Mutation, recombination, repair (Invariant #10)
mutate/2— point ops on the plan (insert/delete/swap) + parameter jitter.recombine/2— one-point crossover of plans; averaged parameters.repair/1— makes ANY genome developable: drop unknown organs → take the prerequisite closure → topologically order by prerequisite depth.
valid?/1 holds for every repaired genome, and mutate/recombine/random all
repair their output. Property tests run hundreds of random genomes and assert
validity (SP.GenomeTest). So evolution never yields an invalid genome without
rejection/repair.
Lineage / evolution timescale
Across episodes, SP.Eval (and a future evolutionary loop) can:
- branch lineages by
mutate/recombine, - select survivors by world viability (envelope reached, ticks survived, infrastructure built, regions expanded),
- seed the next generation's genomes.
The single-episode core already exercises development end-to-end; the
cross-episode evolutionary controller is a thin loop over SP.Genome +
SP.Eval.episode_metrics/1 (see eval harness).
sha256 3a049b5e5baa6652 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
This page describes how a body is inherited, how it grows, and how it changes across generations.
A genome here is deliberately not a rulebook about the world. It is a prior structure that shapes how a body develops: a growth plan naming which organs it will attempt to grow and in what order, how quickly they ripen, and a bias about metabolism, plus bookkeeping about ancestry.
Growth is not free. It spends a budget that accrues only from surplus energy, and each mature organ adds ongoing upkeep, so a body must forage well enough to fund its own complexity. Because growth goes through a function that checks prerequisites and attachment, development cannot produce an impossible body.
Selection happens through the world rather than through a score. No fitness number is ever handed to the agent.
The last section describes the longer timescale, where lineages branch, survivors are selected by how they fared, and the next generation is seeded.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 3a049b5e5baa6652
Clear — written for this website, not the source document
This page covers the hereditary layer of the design: what a genome is here, how a body develops from one, what limits that development, and how change happens across generations.
The genome is defined by what it is not. It is a prior structure that parameterises the growth of a body, and explicitly not a symbolic rulebook about the world, which is named as a hard constraint. Its fields are few: an ordered list of organs the body will attempt to grow, a rate at which organs ripen, a metabolic bias, and bookkeeping for lineage, generation and parents.
Development consumes a growth budget that accrues only from surplus energy. On each developmental tick two things happen. Immature organs ripen a little at a small cost. And if the budget allows, the next organ in the plan whose prerequisites are already mature is grown and attached to its deepest prerequisite part. The developmental stage is derived from the deepest tier of organ present rather than tracked separately. Because growth goes through a function that checks prerequisites and parentage, the page states that development can never produce an impossible body graph, and names the invariant and the property test behind it.
A short section makes the economics explicit. Each mature organ adds upkeep, so morphology is never free and a body must forage well enough to fund its own complexity. Selection happens through the world itself: viability is an envelope, a preferred-state prior and a risk term, evaluated only by the evaluation harness. No fitness number is ever handed to the agent.
The genetic operators are then described: point changes to the plan with parameter jitter, one-point crossover with averaged parameters, and a repair operation that makes any genome developable. Every operator repairs its output, and property tests over many random genomes assert validity.
The last section covers the longer timescale across episodes: lineages branch, survivors are selected by how they fared in the world, and the next generation's genomes are seeded. The page is candid that the single-episode core already exercises development end to end, while the cross-episode controller is a thin loop over existing pieces.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 3a049b5e5baa6652