diff --git a/docs/re/structures/slb-data-offset.md b/docs/re/structures/slb-data-offset.md
index ff38e9a..640cc91 100644
--- a/docs/re/structures/slb-data-offset.md
+++ b/docs/re/structures/slb-data-offset.md
@@ -503,3 +503,43 @@ back to mono only when there is no `RIFF` to read. 7 disc tests pass.
     validate = 'seek' magic at data_at + declared_size          (7 620/7 620)
     samples  = the LAST u32 LE entry in the seek table
     channels = byte at RIFF + 49            <-- read it, never assume
+
+## 🟡 Enumerating every wave on the disc, and a bank→wave assignment rule
+
+**2026-08-26.** `auto/slb-loader` leaves open *"which bank in a window belongs to
+the entry's name"*. This is a measured attempt at it, short of settled.
+
+**Every wave can be enumerated without reference to the TOC.** Scanning the
+1.01 GB flat stream for `seek` and keeping only chunks satisfying
+`size == 8 + 4·count` with a non-negative implied start gives **9 661 waves and
+rejects nothing** — not one false positive in a gigabyte of audio. The identity
+is that strong. Each wave's extent is then `[seek_pos − count·2048, seek_pos)`.
+
+**The assignment rule.** Take an entry to name the **first wave starting at or
+after its offset**. Against the 7 620 entries where the answer is independently
+known (they carry a `RIFF`, so the wave is `data_at` for `declared_size`):
+
+    correct   7 338 / 7 620 = 96.30 %
+    otherwise   282
+
+**The 282 are one class, not a scatter.** In every one, the first wave ends
+earlier than the `RIFF`, and the gap between that wave's `seek` and the first
+`RIFF` is **exactly 12 288 bytes — the same value in all 282**. A constant that
+sharp is structural, not noise. 12 288 is 6 packets, and also 3 × the 4 096-byte
+`RIFF`+`Dmmy` block the other branch identified.
+
+I first guessed these were leading segments, which would put the earlier wave's
+`seek` **at** the first `RIFF`. That is refuted: it happens **0** times out of
+282. Whatever occupies those 12 288 bytes is something else.
+
+❔ **Not settled**: what the 12 288-byte region is, and therefore whether the
+rule should be "first wave at or after the offset" (96.30 %) or that rule with a
+12 288 correction (which would reach 100 % on this set but is curve-fitting
+until the region is identified). **First step**: dump those 12 288 bytes for
+several of the 282 and see whether they are a second `RIFF` block, a padded seek
+table, or audio.
+
+⚠️ Consequence for the open duration question: this does **not** yet unblock
+headerless bank durations. The rule is 96.30 % on entries whose answer is
+checkable; on headerless entries there is nothing to check it against, so
+applying it there would be assuming the very thing that needs proof.