Wiki · Evidence & Verdicts
RED pre-registration — spine-phase3
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 — spine-phase3
- Gate name:
spine-phase3 - Phase: Phase 3
- Pre-registered: 2026-07-13
- Runner:
runs/spine_red.exs - Related:
docs/UNI_MISSION_DEEPENING.md:75-81
Motivation
Phase 3 in docs/UNI_MISSION_DEEPENING.md pre-registers Gate A (byte-identity of default preserved) and Gate B (distal-entropy signature observable in the spine lineage). This is the paired RED harness.
PASS condition
- Gate A (byte-identity):
test/sp/brain/decider_byte_identity_test.exsPASSES with the spine organ present in aspine_lineage/0genome (absent fromdefault/0, coupling 0.0). - Gate B (distal-entropy): In
spine_lineage/0, distal-entropy signature (H(distal states) > baseline by pre-registered ε) is observable in the diagnostic window.
FALSIFIES condition
decider_byte_identity_test.exsFAILS, ORspine_lineage/0shows no distal-entropy signature above baseline in the diagnostic window.
Protocol
- Author
spine_lineage/0genome (segmental spine organ + coupling 0.0 default). - Run byte-identity test (Gate A).
- Run
spine_lineage/0for N ticks in a fixed diagnostic environment. - Measure H(distal states) vs baseline (
default/0in the same env). - Verdict:
- PASS: Gate A PASS + Gate B PASS.
- PARTIAL: Gate A PASS + Gate B ambiguous.
- FAIL: Gate A FAIL (regardless of Gate B) OR Gate B REFUTED.
Ship-gate
Additive+gated invariant preserved. FE code touching lib/sp/brain/motor.ex/motor_control.ex requires this RED PASS before merge.
sha256 686ed392de8f2dea — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
A short record made before an experiment was run. It names a test, states in advance what result would count as a pass and what would count as a refutation, and then stops. It carries no verdict: the outcome is withheld and nothing has been run. Records like this exist so that nobody can decide after the fact what a test was supposed to show. A reader can come back later, find the result, and hold it against the promise made here.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 686ed392de8f2dea
Clear — written for this website, not the source document
A pre-registration is a promise made in advance, and that is all this page is. The work it describes had not yet been run when the page was written, so the verdict is withheld and the evidence is marked as pending.
It opens with a short block of labels: the name of the gate, which phase of the plan it belongs to, the date it was registered, the script meant to run it, and where the related design notes live. Then it says why the test exists. An earlier design document had already committed to two paired checks, and this page is the harness for them. The first asks that a default behaviour stay byte-identical once a new organ exists but is switched off. The second asks that the new lineage leave an observable signature above a baseline, inside a diagnostic window agreed beforehand.
The rest is protocol: build the genome, run the byte-identity test, run the new lineage in a fixed environment, compare it against the baseline, then read the verdict off a table written before any of it happened. A closing rule says code in the affected area must not be merged until this test passes.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 686ed392de8f2dea