diff --git a/code/inventory/SCANNER-API.md b/code/inventory/SCANNER-API.md
index 419bb36..b9053ec 100644
--- a/code/inventory/SCANNER-API.md
+++ b/code/inventory/SCANNER-API.md
@@ -150,15 +150,34 @@ So **decoded output is terminated by CR LF** (`0x0D 0x0A`), and Code type `0x3F`
 enables all symbologies (UPC included). A reader should assemble bytes until
 CR/LF and strip the preamble/postamble.
 
-### Still to confirm on-device
+### Confirmed on-device
 
-The `int 0xCF` calls pass their argument by value in `DX`; replicating this from
-C requires that `p_iow(chan, func, arg)` land `arg` in `DX` (or inline asm). The
-exact ordering of the config-byte writes and the two enable ops, and two helper
-subroutines (`0xD6DC4`, `0xD8DCB`), still need tracing and — crucially —
-**validation on the device**, since none of this can be tested off-hardware. The
-clean alternative remains the **Workabout MX C SDK** `SCANNER.DYL` header, which
-`SCANAPP` was built against.
+- `p_open(&h, "WL2:D", -1)` returns `0`.
+- Issuing control ops **6 then 7** on the channel (`p_iow(h, 6)`, `p_iow(h, 7)`)
+  **triggers a scan**: the laser fires and decodes (green good-read LED). This is
+  reproducible. The trigger is one-shot — it must be re-issued for each scan.
+
+### NOT yet solved: retrieving the decoded data
+
+After a confirmed good read, the decoded barcode could **not** be retrieved from
+the `WL2:D` channel by any tried method:
+
+- `p_iow(h, P_FREAD, buf)` (count-in-`buf[0]` style) — no data.
+- `p_read(h, buf, len)` (synchronous, with length) — no data.
+- `p_ioc(h, P_FREAD, &stat, buf, &len)` + trigger + `p_iowait()` (async) — no data.
+
+The retrieval logic in `SCANNER.DYL`/`SCANAPP` uses relocatable code that does not
+disassemble cleanly without the EPOC16 executable segment map, builds decoder
+command frames (`0xff 0xee …` at `channel+4+0x13`), and performs read/write on a
+**separate handle** (a driver global), suggesting the decoded result is delivered
+by a mechanism other than a plain `P_FREAD` on `WL2:D` (e.g. an auxiliary channel
+or an installed callback / active object). Extracting it reliably needs either:
+
+1. The **Workabout MX C SDK** `SCANNER.DYL` header/category (what `SCANAPP` was
+   built against) — the clean answer; or
+2. A full RE effort: parse the SIBO ROM/executable format, load `SCANNER.DYL` at
+   its correct segment base, and trace the retrieval path — large, and every
+   hypothesis costs an on-device build/test cycle.
 
 ## Error codes seen (from `epocdefs.h`)