diff --git a/crates/gc-extract/tests/disc.rs b/crates/gc-extract/tests/disc.rs
index 6200ccb..09702ab 100644
--- a/crates/gc-extract/tests/disc.rs
+++ b/crates/gc-extract/tests/disc.rs
@@ -7916,6 +7916,14 @@ fn moby_classes_enrichment_survives_the_correct_mapping() {
 
 /// The camera region is nine orthonormal affine matrices sharing a translation.
 ///
+/// `m4` at `0x18ab70` is the live camera orientation.
+///
+/// Established by rotating the camera in the live emulator and measuring which
+/// matrix responds: m4's first row swings 30-37 degrees while the other eight stay
+/// under 4 across the whole sweep. All nine translations move together, so the nine
+/// share one camera position and carry nine orientations, of which this one is live.
+/// `R` for `guard_band` step 1 is rows 0-2 of this matrix.
+///
 /// Read live over PINE: two EE RAM dumps taken seconds apart, then the region at
 /// `0x18aa70` is checked to be a 4x4 matrix whose upper 3x3 is orthonormal and
 /// whose fourth row is a translation that moves smoothly between the two reads.
diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md
index 452946b..10a1254 100644
--- a/docs/plan/level-assets.md
+++ b/docs/plan/level-assets.md
@@ -2861,3 +2861,44 @@ Two cheap checks that would settle it, both needing only the live emulator:
 move the camera and see whether all nine translations move together or only one
 (the former says "one camera, nine cached frames"; the latter says "nine things");
 and change the camera's pitch to see whether the nine rotations reindex.
+
+### m4 is the live camera orientation -- 20x outlier against 8 controls
+
+`d4e81ba` left one question with a two-way answer: is the camera's rotation one of
+the nine, and if so which. Answered by rotating the camera in the live emulator and
+watching which matrix responds.
+
+Ten captures at ~0.6s intervals while the camera was being turned. Angle through
+which each matrix's first row rotated, measured from capture 1:
+
+    idx     1->4      1->7     1->10
+     m0     0.37     0.27      0.53
+     m1     1.31     1.07      1.34
+     m2     3.89     1.38      1.43
+     m3     2.25     1.18      1.40
+     m4    30.60    18.49     37.21     <-- the camera
+     m5     1.70     1.45      1.82
+     m6     1.24     0.98      1.29
+     m7     1.88     1.34      1.73
+     m8     1.70     1.45      1.82
+
+**m4 at `0x18ab70`, and the eight others are the control.** They sit under 4
+degrees across the whole sweep while m4 goes to 30-37 -- a 20x outlier -- and its
+motion is non-monotonic, tracking the input being turned one way then back.
+
+The translations told the complementary half: **all nine move together**, by the
+same few thousandths. So the nine share one camera *position* and carry nine
+different *orientations*, of which one is live and follows the look direction.
+
+**This is what `guard_band` step 1 needs**, and both operands are now located:
+
+    R      rows 0-2 of the matrix at 0x18ab70
+    camera translation, its fourth row: (247.1, 193.4, 50.4) on Aranos
+
+**What this does not establish.** Why there are nine. They are not nine cached
+frames of one camera -- if they were, all nine would have swung by 30 degrees
+together. They are nine distinct orientations about a shared point with one of them
+selected, and a table selected by an index fits. The nine-legal-orientations-on-a-
+spherical-planet reading remains **plausible and unproven**; what is proven is
+which entry is live. No reindexing was observed over the sweep, so if the index
+does move, it does not on camera rotation alone.