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`.