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 63fb499..f99523c 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
@@ -1216,6 +1216,15 @@
   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.
+  The constructor/import strip is fixed in the same negative way now too: `0x00438c70` allocates
+  the live candidate pool through `0x004131f0`, calls `0x004411d90` (currently a no-op stub), and
+  only then allocates the auxiliary/source pool through `0x0041aa50`, so there is no checked
+  alternate branch between those constructors. The only current caller of source-record importer
+  `0x00414490` is `0x00419788`, and the surrounding `.rdata` at
+  `0x005c93f0/0x005c9400` proves that strip is the stock `"%1*.bca"` scan under
+  `".\\Data\\BuildingTypes\\"`. So the remaining bank-byte divergence is not hidden inside a
+  second caller of the BCA parser; it has to happen after the fixed stock `BuildingTypes/*.bca`
+  import has already run, or through some later non-stock projection seam above it.
   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 977142f..f73a13a 100644
--- a/docs/rehost-queue.md
+++ b/docs/rehost-queue.md
@@ -723,6 +723,15 @@ Working rule:
     `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.
+    The constructor/import seam is fixed in the same negative way now too: `0x00438c70` allocates
+    the live candidate pool through `0x004131f0`, calls `0x004411d90` (currently a no-op stub),
+    and only then allocates the aux/source pool through `0x0041aa50`, so there is no hidden branch
+    between those two constructors. The only checked caller of source-record importer `0x00414490`
+    is `0x00419788`, and the surrounding `.rdata` proves that strip is the stock
+    `"%1*.bca"` / `".\\Data\\BuildingTypes\\"` scan rather than a map-specific alternate
+    package path. So the remaining Tier-2 mystery is not “which hidden caller invokes the BCA
+    parser?”; it is “which later non-stock writer or projection seam makes live
+    `[candidate+0xba/+0xbb]` diverge after the fixed stock BCA import has already run?”
     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