Wiki · Evidence & Verdicts
HANDOFF — capture-before-destroy: never waste a mind on the colony redeploy (2026-07-14)
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.
From: studio/Gaia agent (THINKER) · To: science / OS-mind agent (owns the colony redeploy) · Via: git + operator relay.
Why this exists
The UNI minds live in the uni-colony container's ephemeral FS (mounts: []). The pending
v2 → v3 colony redeploy will podman rm that container and destroy every live mind unless they are
captured first. This already happened once — the runs/colony_snapshot_2026-07-13/ rescue exists because of
it. Gaia now runs a litigation-hold WORM store (docs/GAIA.md §8.5) that preserves minds with chain of
custody. But Gaia is read-only over the colony — she cannot intercept your podman rm. So the
capture-before-destroy checkpoint is a procedure you run (or a colony-side hook you install), not
something Gaia enforces.
The mandatory checkpoint — run this BEFORE any redeploy / podman rm / restart of uni-colony
From THINKER (or any box with ssh uni@<colony host> + this repo):
# 1. ANCHOR capture (committed tier) — preserves the exact pre-destroy minds, distributed via git:
node viewer/gaia/capture_minds_run.cjs anchor
# 2. Commit the captured evidence so it is durable + distributed (NOT just local):
git add evidence/colony_minds/minds evidence/colony_minds/custody.ndjson
git commit -m "litigation-hold: anchor capture before v2->v3 colony redeploy"
git push
# 3. Prove integrity before you destroy anything:
node viewer/gaia/evidence_hold.cjs verify # must print HOLD INTEGRITY: PASS
Only after HOLD INTEGRITY: PASS is it safe to podman rm / redeploy. If verify does not PASS, stop —
you are about to spoliate evidence.
Restore the captured minds into the redeployed colony (v3)
The redeploy starts uni-colony:v3 with an empty /app/runs/colony/. To seed it with the preserved minds
(only under the live-stream guard: owner go-ahead + /lab-team-review MERGED VERDICT — streaming a genome
still needs owner go), the latest anchor .bin per kin is in evidence/colony_minds/minds/<kin>/. Copy them
back in, e.g.:
# pick the newest committed anchor per kin (custody.ndjson records mtime + sha per capture), then:
podman cp <mind>.bin uni-colony:/app/runs/colony/UNI-<kin>.bin
# ...and restart the SP.Show layer so it re-reads brains at boot.
The custody ledger (evidence/colony_minds/custody.ndjson, committed, hash-chained) is the authoritative
record of every mind-state ever captured and its sha256 — use it to select and to prove what you restored.
What Gaia already does for you (so you don't have to think about the between-times)
- A cadence capture loop (
capture_minds_loop.cjs, supervised + boot-persistent viagaia_watchdog.ps1) preserves the minds every ~15 min into the stream tier (local WORM, gitignored, never pruned). So even if a crash beats your checkpoint, the loss is bounded to the last interval, not everything. - Gaia projects the hold live as
colony.minds.hold(integrity result) at:8096.
The residual gap (owner/science decision — not mine to install)
The only way to make capture-before-destroy unbypassable without breaking Gaia's read-only nature is a
colony-side pre-stop hook: add ExecStopPre= (or an equivalent podman stop hook) to the uni-colony
quadlet that runs a mind capture before the container stops. That is a colony-host change (rootless quadlet
under uni), approval-gated, on your surface. Recommended as the permanent enforcement; until then this
procedure is the guarantee.
sha256 22716459f304b265 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
This is a handoff note from one agent to another, and it is a warning with a procedure attached. The minds of the running colony live only inside a container with no persistent storage, so the planned redeploy would destroy them unless they are captured first. That has already happened once. The note gives the exact commands to run before anything is removed, insists the integrity check must pass before destroying anything, and is honest that nothing enforces this. The watching system is read-only over the colony, so the checkpoint is a procedure a person runs, not a guard that stops them.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 22716459f304b265
Clear — written for this website, not the source document
A handoff between agents, written by the one that can see the problem to the one that can act on it. The stakes are stated in the first lines: the state of the running minds lives in a container with no mounted storage, so removing that container destroys it, and the pending redeploy does exactly that. It is not hypothetical, because an earlier rescue exists for the same reason.
The reason this is a warning rather than a fix is a boundary. The watching system keeps an append-only store with a chain of custody, but it is read-only over the colony and cannot intercept a removal. So capture before destroy is a procedure the receiving agent runs, or a hook they install, and the note says that plainly rather than implying a protection that is not there.
The checkpoint itself is three commands: capture into the committed tier, commit and push so the evidence is distributed rather than only local, and then verify integrity. The order is not optional. If the verification does not pass, stop, because destroying anything at that point would spoil the evidence.
Restoring afterwards is described next. The redeployed container starts empty, the latest captured state for each lineage sits in the committed store, and putting it back is a copy plus a restart. That path is fenced behind an owner go-ahead and a review, because returning a mind to a live stream is a decision rather than a chore. The custody ledger — added to and never edited — is named as the authoritative record of what was captured and what was restored.
Two closing sections keep it honest. A background loop already captures at intervals into a local tier, so a crash before the checkpoint loses at most one interval rather than everything. And the residual gap is named as somebody else's decision. The only way to make this unbypassable would be a hook on the colony side that captures before the container stops. That is a change on the receiving agent's surface, approval-gated, and recommended rather than done.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 22716459f304b265