Wiki · The Colony & the Method
Production Readiness Report
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.
Subject: THE STRATIFIED PALIMPSEST benchmark environment Verdict: Release candidate — READY for use as a benchmark-class environment to be exposed to a future learning agent, with the documented scope boundaries in limitations.md.
Purpose
Assess whether the repository is implementation-complete, test-complete, QA-hardened, reproducible, and safe to expose to a learner through an opaque interface.
Method
- Full QA suite (
mix test): unit, property, integration, leakage-probe, invariants, soak, golden regression. --warnings-as-errorscompile +mix format --check-formattedin CI.- Live evidence capture (
mix run scripts/evidence.exs). - Manual audit against the spec's Acceptance Gates and 15 Validation Invariants.
Artifacts used
mix test(100 tests, 0 failures).scripts/evidence.exsoutput (reproducibility, leakage, difficulty, ablations, conservation, open-endedness).config/golden/reference_episode.json(regression artifact).- The per-report evidence in this directory.
Result summary (against Acceptance Gates)
| Gate | Status | Evidence |
|---|---|---|
1. mix test passes cleanly |
PASS | 100 tests, 0 failures |
| 2. Property & integration tests pass | PASS | genome/field/dev/interface property suites; SP.SimTest |
| 3. Seeded deterministic runs pass | PASS | reproducibility_report |
| 4. Leakage tests pass | PASS | interface_leakage_audit |
| 5. Ablations show senses/morphology/hidden-layers matter | PASS | sensory, morphology |
| 6. Soak tests stable | PASS | SP.SoakTest (2000 steps, 8× expansion, bounded trace) |
| 7. CI green | PASS (config) | .github/workflows/ci.yml (compile/format/test/golden-diff) |
| 8. Docs sufficient for another team | PASS | docs/ (14 docs) + README + this bundle |
| 9. Production interface hides semantics | PASS | SP.Interface + Audit; leakage audit |
| 10. Final reports written & stored | PASS | this directory (8 reports) |
Engineering quality
- Clean, acyclic module architecture; typed
@specs on public functions; moduledocs throughout. - Zero runtime dependencies ⇒ hermetic, offline, reproducible tests.
- Versioned observation/action schema (
obs-v1). - Containerized (multi-stage
Dockerfile), CI-ready, operator runbook + scripts.
Residual risks
- Live Jido GenServer adapter is specified, not compiled into the offline core (mechanical wrapping; see jido_alignment).
- Difficulty is seed-dependent; use batches for claims.
- Unforced seam expansion is rare from seed bodies (hard late game; proven reachable). See open_endedness_validation.
Sign-off
The environment can be run, tested, and inspected by another team without further clarification. It exposes only opaque channels to learners, hides simulator semantics, carries no reward oracle, and enforces morphology/sense gating and the runtime purity boundary. Recommended for release as a benchmark RC.
sha256 8ab3de0235698eee — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
This is a sign-off report. It asks whether the benchmark environment is complete enough, tested enough and safe enough to hand to another team and to expose to a future learning agent, and it answers that it is a release candidate, within documented scope boundaries.
The method is a full test suite, a strict compile, a formatting check, a live evidence capture, and a manual audit against the acceptance gates and validation invariants written elsewhere.
The centre of the report is a table with one row per acceptance gate, each with a status and a pointer to the evidence behind it, most of which is one of the sibling reports in the same directory.
A short section on engineering quality is followed by residual risks, including one adapter that is specified rather than compiled in, and difficulty that varies with the seed.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 8ab3de0235698eee
Clear — written for this website, not the source document
This is the sign-off report for a benchmark environment, and it states its verdict at the top. It is a release candidate, ready for use as a benchmark-class environment to be exposed to a future learning agent, with scope boundaries documented in a separate file. Naming the boundaries in the verdict itself is what keeps the claim bounded.
The purpose is to assess whether the repository is complete in implementation and in tests, hardened by quality assurance, reproducible, and safe to expose to a learner through an interface that reveals nothing.
The method combines several things. There is a full test suite covering unit, property, integration, leakage, invariant, soak and regression tests. There is a compile in which warnings are treated as errors, together with a formatting check in continuous integration. And there is a live capture of evidence by running a script, plus a manual audit against the acceptance gates and validation invariants defined in the specification.
The artifacts are named with their counts, including a stored reference episode used as a regression guard, and the per-topic reports that sit in the same directory.
The centre of the report is a table with one row per acceptance gate. Each row carries a status and a pointer to the evidence, and most of those pointers lead to a sibling report rather than to an assertion. One row is marked as passing by configuration rather than by observation, which is a distinction worth noticing.
A short engineering-quality section describes the module architecture as clean and acyclic, notes typed signatures and documentation, and stresses that having no runtime dependencies makes the tests hermetic, offline and repeatable. It also mentions a versioned schema for observations and actions, a container build, and an operator runbook.
The residual risks are the honest part. One runtime adapter is specified rather than compiled into the offline core, and the report describes wrapping it as mechanical work. Difficulty depends on the seed, so claims should use batches. And expansion without being forced is rare from a starting body.
The sign-off paragraph restates what the environment exposes and what it hides, and recommends release as a candidate.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 8ab3de0235698eee