diff --git a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
index e493d06..63fb499 100644
--- a/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
+++ b/docs/control-loop-atlas/runtime-roots-camera-and-support-families.md
@@ -1206,6 +1206,16 @@
   block is now well grounded as bundled map/save source data, a direct bulk-import path from that
   block into the live runtime collection `[state+0x66b2]` is still not grounded by the current
   disassembly notes.
+  The startup-side preseed is narrower in the same negative way now too: direct disassembly of
+  `0x00437737` shows the branch iterating the live candidate pool `0x0062b268`, reading bank word
+  `[candidate+0xba]` plus subtype byte `[candidate+0x32]`, and then pushing the candidate stem and
+  one derived boolean through `0x00434f20` into `[state+0x66b2]`; sibling `0x00436ad7` does the
+  same after the status gate `0x0040c990`, but only for subtype-`2` candidates whose bank bytes
+  `[candidate+0xba/+0xbb]` are both zero. The later bring-up caller `0x00444acc` only re-enters
+  that same `0x00437737 -> 0x00434f20 -> 0x00412c10` strip. So these startup passes still consume
+  already-materialized bank/template bytes instead of explaining how live candidates diverge from
+  the all-zero shipped `BuildingTypes/*.bca` corpus before the later `Port%02d` /
+  `Warehouse%02d` rebuild.
   That candidate-side table now has a grounded fixed record layout too: each entry is a `0x22`-byte
   blob with a zero-terminated candidate-name slot at `[entry+0x00..+0x1d]` and one trailing
   availability dword at `[entry+0x1e]`, read through `0x00434ea0` and mirrored later into
diff --git a/docs/rehost-queue.md b/docs/rehost-queue.md
index 0da74c6..977142f 100644
--- a/docs/rehost-queue.md
+++ b/docs/rehost-queue.md
@@ -715,6 +715,14 @@ Working rule:
     candidate pool through `0x004131f0` and the auxiliary/source pool through `0x0041aa50`, and
     both constructors tail directly into the same fixed tagged-import families rather than taking a
     title-specific source-selection branch in between.
+    The startup-side availability preseed is negative in the same way now too: direct disassembly
+    of `0x00437737` and its sibling callsite `0x00436ad7` shows both branches only *reading*
+    live candidate subtype `[candidate+0x32]` plus bank bytes `[candidate+0xba/+0xbb]` and then
+    feeding those predicates into the scenario-side availability table at `[state+0x66b2]` through
+    `0x00434f20`; the later bring-up caller `0x00444acc` simply re-enters that same
+    `0x00437737 -> 0x00434f20 -> 0x00412c10` strip. So even the visible startup preseed still
+    consumes already-materialized bank/template bytes rather than explaining how they became
+    nonzero in the first place.
     So the honest next queue head is now one step earlier again:
     recover the non-stock writer or restore-time projection owner that makes some live candidates
     reach those later consumer strips with nonzero `[candidate+0xba/+0xbb]` despite the observed