Ran the "who writes this" move on the two 3-double vectors the trigger condition pulls out of the unit record. It did not settle them, and it is worth recording why. 99 sites across 40 functions write +32/+40/+48; 16 sites across 13 write +64/+72/+80; six functions write both. The most inviting is sub_821AD218, which is a float-to-double widening copy of exactly 16 floats -- lfs from r4+0..60, stfd to r3+0..120. Sixteen floats is a 4x4 matrix, under which +32/+40/+48 is row 1 and +64/+72/+80 is row 2, making A and B basis vectors rather than positions. That is a tidy story and it is wrong for this record. The disproof was already in hand: sub_8226DAF8 reads `lwz r10, 100(r11)`, a WORD at +100, which falls inside where a 16-double matrix's row 3 (+96..+120) would sit. A second writer, sub_8226A348 -- same built-in shape, [phase+324] indexed by local[4] with the rec+4 liveness check -- confirms a mixed layout: words at +0/+4/+8/+12/+16 and at +80, doubles only at +32/+40/+48. So these offsets recur at the same positions in several unrelated object layouts, and nothing found here ties a specific writer to the object the trigger actually reads. A and B stay unnamed. That is the second tidy reading rejected for them, after previous/current-position. All artefacts regenerate byte-identical; documentation only.