Wiki · Evidence & Verdicts
RED pre-registration — hemispheres-phase5
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.
verdict: WITHHELD evidence_class: pending
RED pre-registration — hemispheres-phase5
- Gate name:
hemispheres-phase5 - Phase: Phase 5 (lateralised hemispheres)
- Pre-registered: 2026-07-13
- Runner:
runs/hemispheres_red.exs - Related:
docs/UNI_MISSION_DEEPENING.md:75-81
Motivation
Phase 5 pre-registers the H3 lateralised genome test: H3 (asymmetric hemispheres) explores more + reaches phase-3 faster than baseline; the SYMMETRIC-DUPLICATE control (same parameter count, symmetric hemispheres) does NOT show H3 — proving asymmetry is the cause, not parameter count.
PASS condition
- Signature: H3 lineage shows exploration advantage over baseline (
default/0) by pre-registered ε. - Control: Symmetric-duplicate lineage (matched parameter count, symmetric hemispheres) does NOT show the H3 signature.
FALSIFIES condition
- H3 signature also appears in the symmetric-duplicate control (parameter-count confound), OR
default_genomebyte-identity breaks with H3 absent.
Protocol
- Three lineages:
- L0 = baseline (
default/0). - L1 = H3 lateralised (asymmetric hemispheres, opt-in genome).
- L2 = symmetric-duplicate control (same param count as H3, but symmetric).
- L0 = baseline (
- Run each for N ticks in an exploration-quality environment (novelty-weighted).
- Measure: state-visit entropy, phase-3 reach time.
- Verdict:
- PASS: L1 > L0 AND L2 ≈ L0 on both metrics.
- PARTIAL: L1 > L0 AND L2 > L0 but L1 > L2 by ε.
- FAIL: L2 ≈ L1 (parameter-count confound).
sha256 779f67ecd85bfa53 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
A promise written before an experiment, and not its result. The idea being tested is that two halves deliberately made unlike each other would explore more than two matched halves. The careful part is the control: a second version with the same number of moving parts, but with its halves matched. If the effect turns up there too, then the extra parts explain it and the lopsidedness does not, and the page says in advance that this would count as a failure. No verdict is recorded here.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 779f67ecd85bfa53
Clear — written for this website, not the source document
Nothing here is a measurement. It is a pre-registration for a planned comparison, written down before the run so that the outcome cannot be reinterpreted afterwards, and the verdict is withheld.
The design is a three-way race. There is a baseline. There is a version whose two halves are deliberately made unlike each other. And there is a control version with the same number of moving parts as that one, but with its halves matched. Each is run for a fixed span in the same kind of environment, and two things are recorded: how widely it wanders, and how quickly it reaches a later stage.
The pass condition is that the lopsided version beats the baseline while the matched control does not. The stated way of showing it wrong is the confound. If the control shows the same advantage, then the extra parts were the cause rather than the arrangement, and the page commits in advance to calling that a failure. A middle verdict is allowed for the case where both improve but one improves more. A separate failure is recorded if an unrelated default behaviour stops being byte-identical.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 779f67ecd85bfa53