Wiki · Evidence & Verdicts
Colony redeploy v2 → v5-9e6cee1 — the chip stops running 3-week-old bytes (receipt, 2026-07-19)
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-seven dated pages: receipts, pre-registrations, handoffs, validation records and review verdicts. A receipt is written at the moment a piece of work was checked. It names what was claimed, the commit and the seed, what was actually run, and the outcome in one of a small set of controlled words. Then it names what the work did not achieve. That last part is what makes it a receipt rather than an announcement. A pre-registration is the same discipline run in advance: the conditions that would count as a pass and the conditions that would falsify the claim are written down before the run, so neither can be adjusted once the numbers arrive.
That is why so many small dated stubs are an audit trail rather than noise. No one of them is meant to be a good read. The value is in the sequence and in the dates, because you can watch a prediction be registered, then the run happen, then the verdict land — sometimes against the prediction. Pages here record a falsified result, a rejected fix, a retracted overclaim, and a green receipt that turned out not to be reproducible from the commit that carried it. A record that carried only successes would be worth a good deal less than this one.
A gentle way in is to read a pre-registration first, so the shape becomes familiar, then a result page, then one of the corrections. This section sits off the main navigation on purpose: it is the record you check the rest of the site against, not the place to begin.
What it is not: documentation, and not a summary. Nothing here has been tidied in hindsight. Every entry reads as of its date, a later entry may overturn an earlier one, and the presence of a page is not a claim that its result stood.
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.
Track: colony/science surface, owner-directed. Genome: Genome.default() (owner-named).
Gate: colony-v5-producer-in-colony — driver=producer + frame advance + colony_count == RCON − Director.
Verdict: PASS · evidence class B (observed-with-artifact: live probes either side of the swap).
CLAIM FENCE: this demonstrates the named behaviour — a real Director/Producer flying the camera over a live colony. It is not evidence of awareness, experience or life. No such claim is made.
1. What was wrong
Per docs/handoffs/SCIENCE_AGENT_COLONY_BRAIN_HANDOFF_2026-07-13.md, the chip ran
uni-colony:v2, built 2026-06-22. The entire Producer / Director / SP.Show show-runner layer
landed 2026-07-11 (24d88f4, 61671b0) — 16+ days later. The colony was alive at the body level
and blind at the camera.
The trap that was avoided. uni-colony:v3 and :v4 exist on the chip and look like the obvious
"next". They are not. Measured build times:
| image | built |
|---|---|
| v1 | 2026-06-22 16:38 |
| v2 | 2026-06-22 16:47 ← was running |
| v3 | 2026-06-23 17:34 |
| v4 | 2026-06-23 21:30 |
| metabolism | 2026-06-25 22:21 |
All five predate the Producer layer. Deploying v3/v4 would have destroyed live minds for a lateral move. The real "next" had never been built. It was built here from a pushed ref.
2. Capture-before-destroy (binding procedure, honoured)
docs/handoffs/GAIA_CAPTURE_BEFORE_DESTROY_2026-07-14.md. The container is mounts: [] — minds live
only in its ephemeral FS.
| capture | when | minds | outcome |
|---|---|---|---|
cap-2026-07-19T03-56-50-314Z |
pre-work | 6 | committed a18b002, pushed |
cap-2026-07-19T05-04-54-680Z |
immediately pre-swap | 6 | committed 2fa59a9, pushed |
cap-2026-07-19T05-12-22-976Z |
before the corrective re-swap | 5 | committed |
node viewer/gaia/evidence_hold.cjs verify → HOLD INTEGRITY: PASS (0 missing, 0 hash
mismatches, 0 custody-chain breaks) confirmed before any destructive step. A second capture was
taken right before the swap so the loss window was minutes, not the ~1h since the first.
The original 6 minds are preserved and NOT restored. The new colony started with an empty
/app/runs/colony/ and bred fresh minds (UNI-1-1/1-2/1-3, UNI-2-1, UNI-3-1). Restoring the captured
lineage is a separate, un-taken decision — the handoff fences it behind owner go-ahead plus a
/lab-team-review MERGED VERDICT. The bytes are in evidence/colony_minds/minds/<kin>/ whenever
that call is made.
3. Genome — verified, not assumed
Owner named default. Verified in code rather than trusted:
# lib/sp/runtime/agent.ex — lineage_from_env/0
case System.get_env("UNI_LINEAGE") do
"homeostat_colony" -> ...
_ -> nil # unset/unknown => nil => Genome.default() => byte-identical
end
The running container carries no UNI_LINEAGE (grep -c = 0, checked post-swap), and the
Dockerfile sets none. The streamed lineage is the byte-identical default.
4. Build — from an immutable pushed ref, not the working tree
Pinned 9e6cee1 (verified docs/gates-only vs the reviewed a18b002, touching nothing the image
ships). git archive 9e6cee1 | ssh … tar -x into ~/build_9e6cee1, then
podman build -t localhost/uni-colony:v5-9e6cee1 -f deploy/uni-os/uni-colony.Dockerfile . → exit 0,
b6022720df90. Shipping from the ref (not the tree) also guaranteed uncommitted local test edits
could not leak into the image.
Image verified to contain the layer before anything was destroyed — the whole point of the redeploy, with v2 as control:
| v5-9e6cee1 | v2 (control) | |
|---|---|---|
show.ex |
PRESENT | MISSING |
/producer/health route |
health_controller.ex |
MISSING |
compiled SP.Show.Bootstrap beam |
PRESENT | — |
compiled SP.Brain.Director beam |
PRESENT | — |
5. The swap — and a mistake worth recording
Sequence: podman rm -f uni-viewer-in (shares the colony netns, blocks removal) → rm uni-colony →
run new → recreate uni-viewer-in → restart uni-producer (its rpc goes stale when the colony's
erlang node restarts).
MISTAKE: the first swap omitted --hostname uni-colony. Podman then set the hostname to the
container ID, so --sname uni formed uni@3435fa92674f instead of uni@uni-colony. The producer
targets UNI_COLONY_NODE=uni@uni-colony, so its Board.all/0 rpc found nothing:
colony_count: 0, star: null, only generic b_roll. Per CLAUDE.md, a colony_count:0 producer
reporting LIVE is an EMPTY colony — it was, and it is recorded as such rather than glossed. Fixed by
re-running with --hostname uni-colony; the env/network/command had been reproduced faithfully but
the hostname was not part of the captured config and should have been.
Restart policy was left at the original no rather than "improved" mid-deploy (one cure at a time).
Recommended follow-up: it should be a restart policy or a rootless quadlet (handoff V7) — a
crash currently leaves the colony down.
6. Proof (probes, not process existence)
driver = producer (the REAL SP.Brain.Director driver, not :self)
OVERLOOK frame = 1 -> 3 across two probes 15s apart => ADVANCE: PASS
colony_count = 5
RCON list = 6 (UNI-1-1, UNI-1-2, UNI-1-3, UNI-2-1, UNI-3-1, Director)
6 - Director = 5 == colony_count => COUNT RULE: PASS
studio /api/status = driver=producer verdict=LIVE colony=5 frame=11
colonycam :3020 = up (prismarine)
The colony's own :4000/producer/health — which 404'd on v2 — now serves, reporting real
cinematography (widen, hold, b_roll with drama scores, star UNI-1-1).
viewer/verify_colony.cjs could NOT be used as the gate. It fails on its RCON leg from THINKER —
the known pre-existing V5 gap (RCON :25575 is not LAN-exposed), not a fault of this deploy. The
count rule was therefore proven chip-side via podman exec mc-server rcon-cli list. Closing V5 would
let the canonical gate run end-to-end and is the right follow-up.
7. Rollback position
uni-colony:v2 is untouched on disk — code rolls back in seconds. Minds do not: they return only via
the litigation hold. That asymmetry is exactly why the capture ran immediately before the swap.
sha256 a9145df935284564 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
A record of replacing a long-running deployment that had been running bytes built weeks before the layer everyone needed. The interesting part is the trap avoided: two newer-looking images existed, and both also predate that layer, so deploying either would have destroyed live state for a sideways move. The real next version had never been built, so it was built from a pushed reference. The minds were captured and their integrity checked before anything was removed, a mistake in the first swap is recorded rather than smoothed over, and the claim is fenced to plumbing.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is a9145df935284564
Clear — written for this website, not the source document
A redeploy receipt — the file recording what was run — with a pass verdict and a stated evidence class, and a line at the top saying what it does not show. It demonstrates the named behaviour, and it is not evidence of awareness, experience or life.
The problem is stated with dates. The running image predated the show-runner layer by more than two weeks, so the colony worked at the body level and was blind at the camera. Then the trap: two later-numbered images exist and look like the obvious next step, and a table of build times shows they also predate the layer. Deploying one would have destroyed live state for a sideways move. The real next version had never been built, so it was built here.
The capture procedure is honoured and recorded as a table of captures, with times, counts and where each was committed. An integrity check passed before any destructive step, and a second capture was taken immediately before the swap so the loss window was minutes rather than an hour. One sentence matters more than the rest: the original minds are preserved and not restored. The new colony started empty and bred fresh ones, and restoring the older lineage is fenced behind an owner decision and a review.
Two things are checked rather than assumed. The named genome is confirmed by reading the code path and then checking that the running container carries no override. And the build comes from an immutable pushed reference rather than from the working tree, which also means uncommitted local edits could not leak into the image. The image is then compared against the old one to show the missing layer is present, before anything was destroyed.
The swap section records a mistake. The first attempt omitted the hostname, so the node name did not match what another component targets, and the result was that component reporting live with a count of zero. The page cites the project's own rule that this reading means an empty colony, and says it is recorded as such rather than glossed. It was fixed by re-running with the hostname, and the lesson is named: the hostname was not part of the captured configuration and should have been. A restart policy was deliberately left alone rather than improved mid-deploy, with the follow-up recommended instead.
The proof is probes rather than the existence of processes: the real driver, a frame advancing between two probes, and a count rule reconciling two independent sources. The checker that counts could not be used because of a pre-existing gap, which is named as pre-existing rather than blamed on this deploy. A closing section gives the rollback position and its asymmetry: code rolls back in seconds, minds do not, which is exactly why the capture ran immediately before the swap.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is a9145df935284564