Wiki · Evidence & Verdicts
Phase 5 item 5.0 — the three premise checks, run before anything was built on them
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.
Date: 2026-07-26 · Repo: UNI.Minecraft, gen2-runtime @ e6a0529
Plan: docs/control-plane/phases/PHASE-5.md §0.1 (UNI-FLAGELLUM)
Item 5.0 exists because four pre-registered premises have been wrong on contact, one per phase. This time the checking came first.
Result: two confirmed, one FALSE — and the plan's own fallback for the false one is false too.
Premise 1 — "a second machine on the mesh can hold an anchor the writer cannot reach"
FALSE. And docs/GAIA.md already said so, in its own words.
The fleet is reachable — replica_ledger_probe.cjs ran clean, three chip
replicas captured. That is not the problem. The problem is what THINKER can
write.
docs/GAIA.md:443-450, verbatim, written before this phase existed:
Caveat (honest): the default target is the colony host — the only box THINKER can ssh-write unattended (node2 is chronically unreachable; MCP writes are approval-gated). That is a second failure domain, not a fully independent custodian (it is the source host). A truly independent target (node2 / an immutable object store) is the further hardening.
And on the existing WORM tier, docs/GAIA.md:438:
Enforcement is procedural. Gaia (read-only) cannot intercept another agent's
podman rm; the unbypassable form is a colony-side pre-stop hook… Until then the handoff procedure is the guarantee.
So on this fleet, today:
| candidate custodian | reachable? | writable by THINKER unattended? | verdict |
|---|---|---|---|
| the colony host | yes | yes — direct ssh key on THINKER | same failure domain; not a witness |
| node2 | chronically unreachable | — | unavailable |
| the existing WORM tier | yes | yes — its immutability is procedural, by its own docs | not a witness |
| any MCP-mediated write | yes | no — approval-gated, one human co-sign | see below |
There is no location on this fleet that the writer cannot reach unattended, except one gated by a human.
The plan's pre-registered fallback is ALSO false
PHASE-5.md §0.1 said: "if false → fall back to a signed anchor and record
why." A signed anchor is only as good as the custody of its key. The key would
live on THINKER, with the writer. A signature the writer can produce is not a
witness — it is theatre with extra steps.
That is a fifth pre-registered premise wrong on contact, and the first one where the fallback was wrong too.
What is actually available, and what it can honestly claim
Two things exist that the writer cannot do unilaterally:
- An approval-gated MCP write. Every mutating call pauses for exactly one human approve/deny. THINKER cannot produce that approval. This is a genuine second party — the same shape as the two-party rule Phase 3 already built.
- A git-distributed anchor. Committed and pushed, the anchor exists in a
remote and in every clone. THINKER can force-push — but a force-push is
visible, and other clones retain the prior history.
GAIA.md:449notes this pattern is already in use: "Anchor + pre-redeploy captures + the anchor custody chain are already git-distributed regardless."
Neither is tamper-proof. Both are tamper-evident, which is a different and weaker claim, and the difference must be stated wherever the witness is described.
This is an operator decision and item 5.1 does not start without it. It changes what the witness can honestly claim, and building the wrong one produces a component whose name asserts something it does not do — the exact failure this programme exists to prevent.
Premise 2 — "gaia_lint.cjs will actually fail a summarizing seat"
CONFIRMED, decisively. The lint is not decorative.
A deliberately summarizing fixture — one signal carrying total,
health_percent and rank, with total also in its id — was written and linted
before any real seat exists:
$ node -e 'require("./viewer/gaia/gaia_lint.cjs").lint({live:false, snapshots:"<fixture dir>"})'
ok: false | snapshot files: 1 | signals: 1
violations: 10
Ten violations across five independent checks:
| check | what caught it |
|---|---|
shape |
envelope missing schema_version |
(a) FROZEN_KEY ×3 |
total, health_percent, rank are outside sig.FROZEN_KEYS.signal |
(b) FORBIDDEN_TOKEN ×4 |
total in the id, total/percent/rank as emitted key names |
(c) PROVENANCE |
declared byte_len ≠ actual |
(d) REHASH |
sha256(value.raw) ≠ provenance.sha256 |
Notably it catches a forbidden token in the signal id, not only in a field — so a seat cannot smuggle a rollup in by naming it.
GAIA LAW is mechanically enforced, not aspirational. Item 5.4 may proceed.
Premise 3 — "Gaia's seat pattern admits a new source without changing GAIA LAW"
CONFIRMED.
organic-operator (added 2026-07-16) is the worked example, and the pattern is
enforced rather than conventional. A seat must be declared in three places:
viewer/gaia/caps.cjsRESOURCES(withseat:),- the
gaia.signal.gettool enum, docs/GAIA.md.
And verify_gaia.cjs's gaia-every-emitted-seat-declared check exists
specifically to close the half-wiring hole that gaia-mcp-caps-agree
structurally cannot see — a seat that emits while being declared nowhere. A new
seat therefore cannot be added quietly.
Its moduledoc also states the law in the form item 5.4 must follow: "Gaia carries the persona TEXT so any reader can run the gauntlet; she never runs it, scores it, or authors its verdict."
No STOP_PROTOCOL_CHANGE_REQUIRED. Items 5.4 and 5.5 may proceed.
Disposition
| item | state |
|---|---|
| 5.0 | DONE. Two premises confirmed, one false with its fallback also false. |
| 5.1 | BLOCKED — operator decision. No unattended-unreachable target exists on this fleet. |
| 5.2–5.6 | UNBLOCKED. Proceed. |
Nothing was built on an unchecked premise. That is what item 5.0 was for, and it earned its place on the first attempt.
sha256 58c0dbf5ad9a99a7 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
Three assumptions checked before anything is built on them, and one comes back false along with the plan's own backup answer. The premise was that another machine could hold a record the writer cannot reach. On this fleet there is no such place, except one gated by a human. The backup was to sign the record instead, but the key would live with the writer, so a signature the writer can produce is not a witness. The work that depended on it is blocked on an operator decision rather than proceeding on a weaker claim.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 58c0dbf5ad9a99a7
Clear — written for this website, not the source document
A premise check written because four earlier premises, all written down in advance, had each turned out wrong on contact. This time the checking came first, and the result is two confirmed and one false, with the fallback for the false one also false.
The false premise is that a second machine could hold an anchor the writer cannot reach. The fleet is reachable, and that is not the problem; the problem is what can be written unattended. The page quotes existing documentation, written before this phase. It admits that the default target is the only machine that can be written to unattended, and is also the source host. That makes it a second failure domain rather than an independent custodian. A table walks each candidate and rules it out. The conclusion is stark: there is no location on this fleet the writer cannot reach unattended, except one gated by a human.
Then the fallback is taken apart. The plan had said to fall back on a signed anchor and record why. But a signed anchor is only as good as custody of its key, and the key would live with the writer. The page calls a signature the writer can produce theatre with extra steps rather than a witness, and notes this is the first time a fallback written down in advance was itself wrong.
What is available instead is stated with its limits attached. An approval-gated write is a genuine second party, because the writer cannot produce that approval. A distributed anchor exists in a remote and in every clone, and while it can be force-pushed, a force-push is visible and the other clones keep the prior history. Neither is tamper-proof; both are tamper-evident, which is a weaker claim, and the page insists that difference must be stated wherever the thing is described. The choice is handed to the operator, because building the wrong one would produce a component whose name asserts something it does not do.
The second premise is confirmed decisively by writing a deliberately summarising fixture and linting it before any real seat exists. Ten violations across five independent checks are listed with what each one caught, including a forbidden word in an identifier rather than only in a field, so the rule cannot be evaded by naming.
The third premise is confirmed by pointing at a worked example and showing that the pattern is enforced rather than conventional. A new source must be declared in three places, and a specific check exists to catch the case where something emits while being declared nowhere.
A closing table gives the disposition item by item, one blocked on the operator and the rest free to proceed, with a line saying nothing was built on an unchecked premise.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 58c0dbf5ad9a99a7