Production Readiness Checklist

The Colony & the Method · docs/PRODUCTION_READINESS_CHECKLIST.md @ 44baf03d5041 (gen2-runtime) — opens the published snapshot ac338733bbba

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.

PlainClearPrecise

Your browser cannot switch reading levels, so the document itself is shown.

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.

Legend: ✅ done · ⬛ specified/extension (see limitations.md)

Code completeness

✅ Hybrid-time world simulator (microstep dynamics, regions, graph, seams)
✅ Layered discoverability L0–L4 with enforced observability barriers
✅ Hidden causal structure (cavities, strain, conduits) + collapse
✅ Ecology (grazer/decomposer/mimic deceptive analog)
✅ Resource economy (8 material classes) + reaction network + hazards
✅ Morphology-gated actions; appendage ladder
✅ Evolving senses unlocking layers; 8 sensor modalities
✅ Developmental transitions (stages 0–4) + growth budgeting
✅ Genome + mutation/recombination/repair; lineage fields
✅ Seam-based open-ended expansion with mutated law vectors
✅ Opaque learner-facing interface (per-seed channels, versioned schema)
✅ Six non-omniscient validation baselines
✅ Eval harness (metrics, ablations, layer-visibility)
✅ Observability (provenance, JSON, CLI table, trace)
✅ Scenario loader with schema validation
⬛ Live Jido.AgentServer/Sensor adapter (specified; pure SP.Sim is the runtime)
⬛ Memory-read-back as a sensor channel (functional ops present)

Runtime boundary (Jido)

✅ Signals primary unit; sensors transduce; pure decide/3; directive-only effects
✅ Internal state ops never mutate world; baselines interface-constrained
✅ No Process.sleep; logical time only

Tests & QA

✅ mix test — 100 tests, 0 failures
✅ Property tests (determinism, conservation, genome/dev validity, leakage)
✅ Integration tests (SP.Sim episodes, reset, fuzz, no-mutation)
✅ Leakage-probe/leakage suite; 15-invariant checklist
✅ Soak tests (2000 steps, 8× expansion, bounded trace)
✅ Golden regression artifact + test

Reproducibility

✅ Pure seed-threaded PRNG; same seed ⇒ identical trace
✅ Provenance capture; versioned schema
✅ Zero deps ⇒ hermetic offline tests

Engineering

✅ @spec + moduledocs on public API
✅ mix format config; --warnings-as-errors clean
✅ GitHub Actions CI (compile/format/test/golden-diff)
✅ Multi-stage Dockerfile; .gitignore/.dockerignore
✅ Operator runbook + deployment guide + scripts

Documentation & evidence

✅ 14 docs (architecture, world, runtime, signal/action catalogs, genome, scenario, eval, QA, runbooks, deployment, reproducibility, security, limitations)
✅ ASSUMPTIONS log
✅ 8 validation reports in docs/reports/
✅ This checklist + production readiness report

Acceptance gates (spec)

✅ 1 mix test clean · ✅ 2 property/integration · ✅ 3 deterministic · ✅ 4 leakage
✅ 5 ablations (senses/morphology/hidden-layers) · ✅ 6 soak · ✅ 7 CI · ✅ 8 docs
✅ 9 production interface hides semantics · ✅ 10 reports stored

sha256 4b668e1fe7a9bc1a — of the original file, so what was ingested stays checkable.

Written for this website — not the document. This is a plain-language retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. Read the document itself → (or choose Precise in the reading-level control above)

Everything here is a checklist, and almost nothing else. It is a list of everything the project said it would build, with a mark beside each item saying whether it is done or whether it is only specified.

The legend at the top is what makes it readable. One mark means finished. The other means specified as an extension, with a separate limitations document named for the detail. Two items carry that second mark, and they are worth finding: one live adapter that is described rather than compiled in, and one memory feature whose underlying operations exist but which is not wired up as a sense.

The rest is grouped by area: how complete the code is, the runtime boundary rules, tests and quality, reproducibility, general engineering, documentation, and finally the acceptance gates from the specification, each with its own mark.

A checklist is a claim about a moment. Read it beside the reports that carry the evidence.

Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 4b668e1fe7a9bc1a

Written for this website — not the document. This is a clearer retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. Read the document itself → (or choose Precise in the reading-level control above)

A completion checklist rather than a report, and it carries no argument and almost no prose: it is a list of items, grouped by area, with a mark beside each one.

The legend at the top does the important work. One mark means done. The other means specified, or an extension, and points at a separate limitations document. Because both marks appear on the same list, a reader can see at a glance where the boundary between built and described actually falls. Two items carry the second mark. One is a live runtime adapter, described as specified while a pure component is the actual runtime. The other is reading memory back as a sense channel, where the underlying operations exist but the channel does not.

The groups follow the shape of the project. Code completeness covers the simulated world and its layered structure, hidden causal structure, an ecology including a deceptive element, and a resource economy with hazards. It covers actions gated by body parts, senses that unlock layers as they develop, developmental stages, and an inheritable genome with mutation and recombination. And it covers open-ended expansion into regions with altered law, an interface that hides its meanings from the learner, several non-omniscient reference strategies, an evaluation harness, observability, and a scenario loader.

A short group restates the runtime boundary: signals are the unit, decision logic is pure, effects happen only through instructions, internal operations never change the world, and time is logical rather than taken from a clock.

The remaining groups cover tests and quality assurance, including property, integration, leakage, soak and regression tests. Then reproducibility, resting on a threaded generator and having no dependencies. Then engineering practice, and documentation and evidence, which points at the validation reports that sit elsewhere.

The last group maps the specification's acceptance gates one by one, each with a mark. That is the part a reader checking claims should treat as an index into the evidence rather than as the evidence itself, since a checklist records a moment, and the reports carry the records of what was run.

Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 4b668e1fe7a9bc1a

Production Readiness Checklist

How to read this page

Precise — the source document