diff --git a/code/inventory/README.md b/code/inventory/README.md
index 835674d..7404c2d 100644
--- a/code/inventory/README.md
+++ b/code/inventory/README.md
@@ -8,12 +8,12 @@ Written in PLIB C, built with the TopSpeed compiler (`tsc /m scan`).
 
 ## Phases
 
-- **Phase 1 (this commit): scan and validate.** Reads barcodes from the scanner
-  and prints each one, flagging whether it is a valid UPC-A.
+- **Phase 1 (current): scan and validate.** Read UPC barcodes from the integral
+  laser and display them.
   Modules: `upc` (validation), `bcode` (scanner input), `scan` (the demo).
 - **Phase 2 (next): inventory database.** A DBF file keyed on UPC holding a
-  quantity and a name. Scan to add stock (increment, or create on first sight),
-  scan to consume by a quantity unit. Built on the SIBO `Dbf*` API.
+  quantity and a name. Scan to add stock, scan to consume by a quantity unit.
+  Built on the SIBO `Dbf*` API (`p_dbf.h`).
 
 ## Build
 
@@ -21,37 +21,43 @@ Written in PLIB C, built with the TopSpeed compiler (`tsc /m scan`).
 tsc /m scan
 ```
 
-Produces `scan.img`. `scan.pr` compiles `upc.c`, `bcode.c` and `scan.c` and
-links them.
+Produces `scan.img`. `scan.pr` compiles `upc.c`, `bcode.c`, `scan.c` and links
+`scan.img`.
 
-## How the scanner is read
+## How the scanner is read (important)
 
-On the Workabout the barcode module decodes the label in hardware and sends the
-result as an RS232 stream, so there is no special barcode driver call: the app
-opens the serial port and reads it. The scanner is on the top internal slot,
-which is port **D**, so the device is `TTY:D` (`bcode.c`).
+The Workabout MX integral laser is an **undecoded (HHLC)** scanner: it emits a
+raw bar/space signal, not decoded ASCII. The hardware serial decoder in the
+RS232/Barcode module handles only wands and wand-emulation scanners — the HC
+guide explicitly lists "Undecoded Laser Scanner (HHLC)" as **unsupported** there.
+That is why reading `TTY:D` directly returned nothing even though the laser's
+own good-read LED lit.
 
-The scan loop is blocking: it reads the scanner and prints each barcode; you
-exit via the System screen. (An asynchronous scan-or-Esc loop was tried but
-panicked the Window Server: on SIBO the keyboard is event-driven through the
-window server, not a raw `CON:` byte read, and a proper async loop needs the
-Window Server event API, whose reference manual is not in this repo's `docs/`.)
+The decode is done in **software** by a barcode decoder LDD. The SDK ships
+several in `\SIBOSDK\LIB`; each registers the device `BAR:`:
 
-This Phase 1 build also prints the byte length of each decoded barcode, so the
-exact format the scanner emits for a UPC can be confirmed before Phase 2 uses
-it as a database key.
+| LDD | Symbology |
+| --- | --- |
+| `BAREAN.LDD` | EAN / **UPC** |
+| `BARC39.LDD` | Code 39 |
+| `BAR128.LDD` | Code 128 |
+| `BARITF.LDD` | Interleaved 2 of 5 |
+| `BARMPLES.LDD` | MSI Plessey |
+| `BARRAW.LDD` | raw / undecoded |
 
-## Things to confirm on the device
+So the flow is: `p_loadldd("BAREAN")` → `p_open("BAR:")` → read decoded
+barcodes. **`BAREAN.LDD` must be present on the device** for `p_loadldd` to find
+it (copy it from `\SIBOSDK\LIB`, or load it via the system config).
 
-Because this cannot be compiled or run off-device, these points are written to
-the SDK docs but may need adjusting once you build and test:
+The current build is a **diagnostic**: it dumps every byte of each read
+(`n=<count>: <decimal bytes> "<printable>"`) so the exact decoded format — length,
+any type/prefix byte, terminator — can be confirmed before the reader and the
+Phase 2 database key are finalised.
 
-- **Serial line settings.** `bcodeOpen` opens `TTY:D` with the default mode. If
-  the scanner needs a specific baud/parity/framing, configure the channel with
-  `p_iow(chan, P_FSET, &config)` (E_CONFIG, `p_config.h`) after opening.
-- **Terminator.** `BCODE_TERM` in `bcode.h` is set to CR (`0x0D`), the common
-  case. Change it if your scanner suffixes LF or something else.
-- **Raw scan format.** The build prints `len=NN [text]` per scan. Confirm
-  whether a UPC arrives as exactly 12 digits or with extra characters (a
-  leading zero / EAN-13, or a symbology prefix); Phase 2 normalises to the
-  database key based on this.
+## The `BAR:` read protocol
+
+The precise read semantics of `BAR:` (data format, any symbology configuration
+via escape sequences) live in the I/O Devices Reference manual, which is not
+among the committed docs. The diagnostic build exists to establish that format
+empirically. Once a scan prints, the reader (terminator handling, UPC
+validation via `upc.c`) and Phase 2 follow.