diff --git a/docs/re/ui-quad-class-foothold.md b/docs/re/ui-quad-class-foothold.md
index 122e147..861295c 100644
--- a/docs/re/ui-quad-class-foothold.md
+++ b/docs/re/ui-quad-class-foothold.md
@@ -76,3 +76,45 @@ Two reasons, neither of which is "it looks right":
 **Not settled:** everything the search was actually for. No function that
 iterates screen elements has been found, and nothing here bears on the paint
 order yet.
+
+## Second pass: the drawing API is small, and a UI item is 244 bytes
+
+Continuing the search for the element walk (2026-08-19). Three more facts, none
+of which is the walk:
+
+* **The drawing API is enumerable.** The renderer accessor `sub_823C2AC0` — the
+  one the quad emitter calls to get its vertex pointer — has exactly **6
+  callers**, and four of them (`sub_821D6A40`, `sub_822380B0`, `sub_82234610`,
+  `sub_821BC718`, ~160 instructions each) are sibling quad emitters. So the
+  number of places in the whole title that can emit a UI quad is small enough to
+  enumerate, which is worth knowing before instrumenting anything.
+
+* **`sub_823C2990` is a factory, not a singleton accessor** — a correction to
+  what its use inside the top-level render function suggested. It allocates twice
+  from a heap held at `[0x828E2B14]` via `sub_82150EF8`: 4 bytes for a handle,
+  then **244 bytes** for the object, and runs `sub_823DE0C0`, which is the head
+  of the chain that ends in `sub_823CB2A0` — the constructor that installs
+  vtable `0x820b30b4`. So **a UI item object is 244 bytes**, and the "LOGO item"
+  class named in the emulator-era notes is what this factory builds.
+
+* **The `0x823C…` region is the screen/bundle subsystem.** It contains both the
+  item class (constructors at `823CB2A0/823CB558/823CBB90`, methods
+  `823CE558…823CFD90`) and four of the functions that load the `RATC` fourcc
+  (`823CAF10`, `823CABE0`, `823CB1F0`, `823CBEE8`), so bundle parsing and item
+  construction live together.
+
+## Stated plainly: this is becoming a rabbit hole
+
+Three iterations have added map without answering the question. The searches keep
+landing on *construction* and *emission*, never on the per-frame walk that orders
+elements — and each step is a plausible next query rather than a decisive test,
+which is the shape of a search that can run indefinitely.
+
+The decisive alternative, costed rather than started: the vertex buffers the
+capture already records (`vb=0x14D10B90`, …) are written by the **guest CPU**
+just before the draw. A Canary memory watch on that range would report the guest
+**PC** doing the writing, which names the emitter and its caller directly instead
+of inferring them. That is a real change to the emulator (the watch machinery
+exists for shared-memory invalidation, not for reporting PCs), so it is the next
+thing to weigh — against simply leaving the paint order unresolved, which costs
+the port one screen's fidelity and nothing else.