diff --git a/docs/re/captures/stage05-mission-approach.png b/docs/re/captures/stage05-mission-approach.png
new file mode 100644
index 0000000..df74a67
Binary files /dev/null and b/docs/re/captures/stage05-mission-approach.png differ
diff --git a/docs/re/structures/xbg7-mesh.md b/docs/re/structures/xbg7-mesh.md
index e20e893..30d54b9 100644
--- a/docs/re/structures/xbg7-mesh.md
+++ b/docs/re/structures/xbg7-mesh.md
@@ -1508,3 +1508,45 @@ decode `_rou_f402_dead` to a *clean but wrong* block, so several degenerate-free
 candidates exist and file order picks badly. The majority span would separate
 them — but "flag, don't silently rewrite geometry on a vote" still stands, so this
 needs the box-identity data, or a capture of a stage that draws it.
+
+### A capture from a DIFFERENT mission — out-of-sample validation, and how containers get loaded (2026-08-13)
+
+With the stage now selectable from a hand-edited save
+([savegame notes](savegame-format.md#-solved-52-is-the-stage-and-the-save-picks-the-mission-2026-08-13)),
+`ship_capture_close.sh` was run in **story stage 05** (`Lebendorf_far`, the Gallia
+asteroid field) instead of stage 02 — three logs, ~11 200 draws, target
+`UN_f105_TCAF_Cruiser` closed to 1 375 units.
+
+**The pad fix validates out of sample.** These draws had no part in deriving it:
+
+```
+index runs compared: 124 identical · 0 differing · 4 no decoded resource
+2 769 index elements checked against the GPU
+```
+
+So 124/124 index runs from a mission the fix never saw agree byte for byte, on top
+of the 93/93 from the stage-02 capture.
+
+**A mission has SEVERAL stage containers resident, and the drawn buffers split
+between them.** Scoring the same logs against two containers:
+
+| container | its own load constant | drawn buffers placed | what they are |
+|---|---|---|---|
+| `Stage_S02.xpr` | `0x17FE3FF4` (same as the stage-02 run) | **65** | the shared TCAF/ADAN fleet — `f105_*`, `e105_*`, `e106_*`, `f106_*`, `_rou_*` |
+| `Stage_S05.xpr` | `0x1927B7F4` | **5** | the **f101 ACROPOLIS** (`bdy_01/02/03`, `eng_01`, `wep_01`) — the mission's escort |
+
+Both sets have exact index counts and exact pool coverage, so both placements are
+real. The split is explained by content, not by guesswork: `f105_bdy_01` is in
+**13 of the 22** stage containers and **not in `Stage_S05.xpr` at all**, while the
+f101 parts the engine drew match S05's own copy. So the resident set follows the
+**mission's unit roster** — every mission that fields the common fleet pulls the
+container that holds it (`Stage_S02.xpr`, the largest at 57 MB), while its own
+container supplies what is unique to it.
+
+**Consequence for the remaining 82–85 misses:** flying a different *story* stage
+is not the same as reaching a different *container*. To cover a specific container
+one has to pick a mission whose roster contains units that live **only** there —
+which is a static question (resource names per container × the stage's
+`EnumUnit_SNN` roster), not another capture run. That is the cheap way to aim the
+next capture, and the first-ever truth rows for a non-`Stage_S02` container (the
+five f101 rows above) show the method works the moment the roster does.