diff --git a/docs/plan/level-assets.md b/docs/plan/level-assets.md
index 10a1254..a3ab57b 100644
--- a/docs/plan/level-assets.md
+++ b/docs/plan/level-assets.md
@@ -2902,3 +2902,52 @@ selected, and a table selected by an index fits. The nine-legal-orientations-on-
 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.
+
+### Frustum search: bounded, not found
+
+`e7eec01` located `R` and the camera. The remaining operand is the frustum --
+`near`, `far`, `tan`. Searched with the same shape of filter that found the
+camera: a structural invariant first, a differential second.
+
+**First attempt, discarded.** Scanning for a perspective-matrix signature (a
+nonzero `col3` in row 2 with zero elsewhere) returned **11,846 hits**. That is
+noise, and the filter was worthless. Recording it because the number looks like a
+result and is not.
+
+**Second attempt, the right filter.** Unit-length 3-vectors at 16-byte alignment --
+the same invariant that identified the camera's matrices. 9,514 of them, of which
+188 form clusters of four or more within 256 bytes:
+
+    0x1793f0 .. 0x1796d0    36 vectors, 736 bytes
+    0x189e20 .. 0x189e80     6 vectors,   96 bytes
+    0x18a550 .. 0x18a580     4 vectors,   48 bytes
+    0x18aa70 .. 0x18ac90    27 vectors,  544 bytes   <- the nine camera matrices
+    0x18b260 .. 0x18b640    49 vectors,  992 bytes
+
+**The six-vector cluster at `0x189e20` is a frustum's shape** -- six planes is the
+right count and 96 bytes is the right size -- and it is not one. It reads:
+
+    0x189e20  [-0.4106,  0.9118, 0.0001]  |x|=1.0000
+    0x189e30  [-0.9118, -0.4106, 0.0001]  |x|=1.0000
+    0x189e40  [ 0.0001, -0.0001, 1.0000]  |x|=1.0000
+    0x189e50  [ 0.0000,  0.0000, 0.0000 ]  w=1.000
+    ... repeats at 0x30 stride ...
+
+Three unit vectors and a zero affine row: an orthonormal basis with no
+translation, which is an orientation record, not a plane set. A translation sits
+at `0x189ea0` = (246.857, 193.205, 49.891) -- near the camera position, so this
+region is a table of positioned things.
+
+**So the frustum is still not located, and I am not going to pick the six-vector
+cluster because six is the number a frustum has.** That would be rule 4's failure
+with an exact number attached to make it feel earned, which is the specific thing
+this project keeps warning about and the thing I have already committed twice in
+this investigation.
+
+**What the search did establish:** the camera-adjacent structured regions in EE
+RAM are the nine matrices at `0x18aa70`, orientation records at `0x189e20`, and
+larger clusters at `0x1793f0` and `0x18b260`. The frustum, if it is stored as
+planes, is not among them. If it is stored as `near`/`far`/`tan` scalars -- which
+is what `guard_band`'s signature suggests, since it takes `Frustum { near, far, tan }`
+rather than six planes -- then the search should be for a stable float pair with a
+plausible ratio, not for normals at all. That is the next search, and it is cheap.