From 232550595d424aadcf7836ef6c4022511c0aaf91 Mon Sep 17 00:00:00 2001 From: alex Date: Wed, 9 Sep 2026 03:25:02 -0400 Subject: [PATCH] lane BU: run 1's result reshapes the prediction; the run-2 test committed before run 2 finished Run 1 falsified P3 as written -- the walk is NOT ascending element address, 0 of 5 sequences -- and handed back a sharper key: it is lexicographically ascending in (fleet->Location*, fleet*), 5 of 5. Both are heap addresses. Run 1 also found something the static read had missed: the newly minted fleet ids are ALREADY on the fleet objects when the assignment walk claims them, so the id-to-group pairing is decided upstream of AssignFleetsAndIssueOrders. The cross-process test that separates 'the Location pointer is the key' from 'the Location pointer is a correlate' is committed here, while run 2 was still loading and before its autosave existed. --- .../fleet-visit-order-mechanism.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/findings/control-flow/fleet-visit-order-mechanism.md b/findings/control-flow/fleet-visit-order-mechanism.md index b5a8bd4..4077eb6 100644 --- a/findings/control-flow/fleet-visit-order-mechanism.md +++ b/findings/control-flow/fleet-visit-order-mechanism.md @@ -279,3 +279,43 @@ here, exactly as in BP and BR. *(To be filled in after the runs. This section is empty in the commit that carries the prediction.)* + +--- + +## 2.6 A second prediction, committed after run 1 and **before run 2's autosave existed** + +Run 1 is in and it did two things at once: it **falsified P3 as written** and it named a **sharper +key** than P3 had. Rule 2 says a prediction exists to be disagreed with, and the honest move when a +measurement hands you a better model mid-lane is to commit the new model as a prediction *before* +the next run, not to present it afterwards as what was meant all along. So: + +**What run 1 measured** (details and the full log in §3). The walk order over the acquired-fleet +vector is **not** ascending element address — 0 of 5 multi-element sequences. It is +**lexicographically ascending in `(fleet->Location*, fleet*)` — 5 of 5**, with the fleet pointer +breaking the tie in the one sequence where two fleets share a Location. Both keys are heap +addresses. And the newly minted fleet ids are **already on the fleet objects at claim time**, so +the id↔group pairing is decided *upstream* of this function and this walk inherits it. + +**The committed prediction for run 2**, written at 07:26 UTC while run 2 was still loading: + +> **Q1.** Run 2's `aivisit` log is again `(loc, elem)`-lexicographically ascending in every +> multi-element sequence, and again not ascending in `elem` alone. +> +> **Q2 — the cross-process test, and it is the one that matters.** Identify the two groups by +> their ships, which are process-independent: the **system-384 group is the fleet holding ship +> 6976**, the **system-80 group is the fleet holding ship 5264**. In run 1, `loc(384-group)` = +> `0x3205b040` < `loc(80-group)` = `0x3205eb90`, and the autosave was `e913ff41…` — the branch on +> which **384 is visited first and takes id 1970**. Therefore: +> +> * if run 2's autosave is `724528ff…` (the 80-first branch, `(80,1970) (384,1986)` in list 10), +> then in run 2 **`loc(80-group) < loc(384-group)`** — the two Location objects land in the +> opposite relative order; +> * if run 2's autosave is `e913ff41…` again, then **`loc(384-group) < loc(80-group)`** again. +> +> **Falsifier:** the ordering relation between the two Location addresses failing to agree with +> the branch. That would say the Location pointer is a correlate on one process and not the key, +> and would push the mechanism back toward H1b or toward some third key. +> +> **Q3.** The fleet ids carried on the elements at claim time follow the same relation: on the +> `e913ff41…` branch the fleet holding 6976 carries `fid=1970`; on the `724528ff…` branch it +> carries `fid=1986`.