diff --git a/artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-sequencing-note.md b/artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-sequencing-note.md
index 196f990..cae2fc6 100644
--- a/artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-sequencing-note.md
+++ b/artifacts/exports/rt3-1.06/runtime-effect-kind8-tier2-sequencing-note.md
@@ -38,7 +38,8 @@ The later explicit `0x197` checkpoint at `0x00444ac1` sits:
 - and then `0x00434d40`
 
 So the late Tier 2 strip begins with named-availability preseed and latch refresh, not with the
-shell progress or territory overlay helpers that precede it.
+shell progress or territory overlay helpers that precede it, and it ends with one extra subtype-`2`
+mark pass rather than stopping at the named-availability latch refresh.
 
 ## Internal Tier 2 rebuild relationships
 
@@ -60,8 +61,12 @@ Current grounded internal relationships:
   - rebuilds candidate runtime records from scenario state
   - does not consult the scenario-side recipe-book name at `[state+0x0fe8]`
 - `0x00412fb0`
-  - broader collection load owner that re-enters `0x004120b0`, then `0x00412d70`,
-    then `0x00412ab0`, and only after its later catalog rebuild re-enters `0x00412c10`
+  - broader collection load owner that directly loops through `0x004120b0`, then calls
+    `0x00412d70`, then `0x00412ab0`, and only after its later catalog rebuild re-enters
+    `0x00412c10`
+- `0x00434d40`
+  - late post-refresh sweep over collection `0x0062b26c`
+  - sets `[entry+0x7b0] = 1` for subtype-`2` rows
 
 ## Current recovery implication
 
@@ -75,5 +80,5 @@ The strongest remaining Tier 2 question is sequencing, not naming:
   and the broader load-side rebuild owner
   `0x00412fb0`,
   with the early checkpoint only conditionally refreshing `0x00412c10` but the late checkpoint
-  always rerunning `0x00435630 -> 0x00437737 -> 0x00412c10`,
+  always rerunning `0x00435630 -> 0x00437737 -> 0x00412c10 -> 0x00434d40`,
   rather than on a direct `Warehouse05` availability bit or recipe-book display-name leak.
diff --git a/docs/rehost-queue/tier2-rebuild-sequencing-2026-04-21.md b/docs/rehost-queue/tier2-rebuild-sequencing-2026-04-21.md
index 6d9f30c..60ec9d1 100644
--- a/docs/rehost-queue/tier2-rebuild-sequencing-2026-04-21.md
+++ b/docs/rehost-queue/tier2-rebuild-sequencing-2026-04-21.md
@@ -23,9 +23,9 @@ owners form one coupled strip:
   - also re-enters `0x00411ce0` and `0x00411ee0`
 - `0x00412fb0`
   - broader collection-load owner
-  - re-enters `0x004120b0`
-  - then `0x00412d70`
-  - then `0x00412ab0`
+  - directly loops through the stock/import stream via `0x004120b0`
+  - then calls `0x00412d70`
+  - then calls `0x00412ab0`
   - and only after the later catalog rebuild re-enters `0x00412c10`
 - `0x00437737`
   - late preseed of named candidate-availability records from the live pool
@@ -36,6 +36,9 @@ owners form one coupled strip:
 - `0x00412c10`
   - refreshes `[candidate+0x7ac]` from named availability
   - then tails into `0x0041eac0`
+- `0x00434d40`
+  - late post-refresh sweep over collection `0x0062b26c`
+  - sets `[entry+0x7b0] = 1` for subtype-`2` rows
 
 ## Late Bringup Placement
 
@@ -68,7 +71,7 @@ Fresh `objdump` over `RT3.exe` now makes the two key bringup checkpoints explici
 
 So the late bringup strip is not just “somewhere after `0x004354a0`.” It explicitly reruns the
 recipe/runtime rebuild before the named-availability preseed and the later unconditional latch
-refresh.
+refresh, and then runs one final subtype-`2` mark pass through `0x00434d40`.
 
 ## Current Reading
 
@@ -80,6 +83,8 @@ This keeps the active Tier-2 owner question on sequencing and data handoff, not
   `0x00437737 -> 0x00434f20 -> 0x00412c10`
 - the early checkpoint only refreshes `0x00412c10` when the live candidate pool already exists,
   while the late checkpoint always reruns `0x00435630 -> 0x00437737 -> 0x00412c10`
+- the same late checkpoint then follows with `0x00434d40`, which walks `0x0062b26c` and stamps
+  `[entry+0x7b0] = 1` on subtype-`2` rows
 - the remaining non-hook question is how that interaction lets candidate-table rows
   `35/43/45..66` reach `0x00412d70` with nonzero `[candidate+0xba/+0xbb]` before the later
   `0x00419230` rebank-or-clone pass consumes them