Wiki · Evidence & Verdicts
Phase 6 item 6.0 — premises checked, and each check's blind spot named
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 @ 915bfbb
Plan: docs/control-plane/phases/PHASE-6.md §0.1 (UNI-FLAGELLUM)
Phase 5 taught that a premise check can itself be incomplete — it found three declaration sites where there were four. So this item checks the premises and states how each check could be wrong.
Result: one confirmed, one confirmed-with-a-correction, one FALSE — and the false one was caught by the blind spot written for it.
Premise 1 — "uni-approvald can carry a human co-sign for a key"
CONFIRMED, with its limitation stated.
approvals_pending answers live: ok: true, count: 0, and the envelope says
in its own words:
these are waiting for a HUMAN at
https://<box>/approvals/— you cannot approve your own request
That is a genuine second party. The split is categorical, not per-verb: "each mutating call pauses for ONE human approve/deny… read-only tools run at once."
How this check could be wrong. The blind spot named was "it may gate only some verbs; enumerate them rather than sampling one." I did not enumerate every tool and observe each one gate. I read the stated rule and observed the queue exists and refuses self-approval. So the claim is: the mechanism is real and categorical by declaration, not every mutating tool was individually verified to gate. A tool that quietly bypassed the queue would not have been caught by this check.
Premise 2 — "a room transition can be recorded with the existing command vocabulary"
FALSE. The ledger entry has no home for a second key.
The blind spot for this check was "a transition may need a field the entry has no home for — check the DATA-SPEC, not just the code." That is what caught it.
DATA-SPEC.md §1:
authorization| object | ✔ |{kind, granted_by, ref}— how this was permitted
One granted_by. And Command validates exactly that:
missing = Enum.reject(["kind", "granted_by"], &is_binary(Map.get(auth, &1)))
An airlock (F20) needs two valid keys, and the entry can carry one
authority. Grepping command.ex for co_sign|signers|keys returns 0.
Had I checked only the command vocabulary — which is genuinely extensible, and whose extension is legitimate under the standing rule "the vocabulary grows only when a guard grows with it" — I would have concluded the premise held, built the Room, and discovered at F20 that two keys cannot be recorded.
Remedy, additive so nothing already written breaks: authorization gains an
optional co_signers array. Command validates that each is a distinct party
and that none equals the actor, reusing the two-party comparison already built
in Phase 3 (case- and whitespace-insensitive). The seven entries already in the
Control Plane ledger remain valid — they carry no co_signers and need none.
DATA-SPEC.md §1 is amended, which is the second correction to that section.
The first was Phase 3's prior rule.
Premise 3 — "no existing surface already models rooms"
CONFIRMED-WITH-A-CORRECTION. Nothing models a lab room; a gated progression already exists.
Grepping under several names:
airlock 0 · sterile 1 · cleanroom 0 · chamber 0 · room 20 · stage 117 · mode 383 · zone 56
stage and mode are too broad to mean anything — which is the blind spot
verbatim: "a differently-named equivalent (a 'stage', a 'mode') would not match a
grep for 'room'."
Looking for the shape rather than the word found it: viewer/door_journey.cjs
already models a gated progression — studio_ready → feature_test → go_live → run_of_show → off_air, each step a {id, label, check} whose check returns
{done, detail}, where detail explains why not yet in words a reader can act
on:
"not yet green — run BROADCAST TEST from the command center"
That is the same discipline item 6.1 requires ("the refusal names the missing receipt"), already in use on this platform.
What this changes. Room does not reinvent the shape — it mirrors
{id, check → {done, detail}}. It is still a different body (ADR-0001):
the Door governs a broadcast threshold and its checks are probes of live
state; a Room governs a lab threshold and its conditions are receipts.
Same vocabulary, different subject, no collapse.
Disposition
| premise | state |
|---|---|
| 1 — approvals can carry a co-sign | CONFIRMED, by declaration not per-tool enumeration |
| 2 — the entry can record a room transition | FALSE — no home for a second key. Additive remedy named. |
| 3 — nothing already models rooms | CONFIRMED-WITH-CORRECTION — reuse door_journey's shape, do not reinvent it |
Two phases running, item N.0 has found something that would otherwise have been discovered late and expensively. The blind-spot column earned its place on its first outing.
sha256 b047ab5c1811850b — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
This page checks three assumptions before anything gets built on them, and it also writes down how each check could itself be wrong. That second habit is what earns its place: one premise turned out false, and the named blind spot is what caught it. The false one is that an existing record could hold a two-key handover, when it has room for a single authority. The remedy is additive, so nothing already written breaks. Another premise is confirmed with a correction, because something under a different name already had the shape that was about to be reinvented. It is a gated progression whose every step can say why it is not yet done, in words a reader can act on.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is b047ab5c1811850b
Clear — written for this website, not the source document
A premise check, written because an earlier phase learned that a premise check can itself be incomplete: it had found three sites where there were four. So each check here is followed by a plain statement of how it could be wrong.
The first premise, that a human co-sign can be carried, is confirmed with its limitation attached. The queue answers live and it refuses self-approval, which is what makes the second party real. But the check read the stated rule and observed the queue, rather than enumerating every tool and watching each one gate. The page says so, and says what follows: a tool that quietly bypassed the queue would not have been caught by this check.
The second premise is false, and the blind spot written for it is exactly what caught it. The instruction had been to check the data specification rather than only the code, and the specification allows one granting authority per entry. A two-key threshold needs two, and a search for anything like a second signer finds nothing. The counterfactual is spelled out: checking only the command vocabulary, which is legitimately extensible, would have led to building the thing and discovering the problem late. The remedy is additive, an optional list of co-signers checked as distinct parties none of whom is the actor, reusing a comparison built in an earlier phase, so the entries already written stay valid.
The third premise is confirmed with a correction. Nothing models the thing by name, and the search for the name is admitted to be nearly useless, because the alternative words are far too common to mean anything. Looking for the shape instead found an existing gated progression whose steps each carry a check returning whether it is done and, if not, a sentence saying why not yet, in terms someone can act on. That is the same discipline the next item requires. So the new thing mirrors that shape rather than reinventing it, while staying a separate body. One governs a broadcast threshold through probes of live state; the other governs a lab threshold through receipts, the files recording what was run.
A short table summarises the three dispositions, and a closing line notes that this practice has now twice found something that would otherwise have surfaced late and expensively.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is b047ab5c1811850b