diff --git a/README.md b/README.md
index 2a92c56..a33a46e 100644
--- a/README.md
+++ b/README.md
@@ -16,9 +16,21 @@ A **first concrete goal** for this stack is to support **PCIe hot-swap (hot-plug
 
 That work fails if the bench is informal—wrong port, wrong power path, or no shared picture of what was connected when. FiWiControl targets that gap by combining **documented inventory** (INI + **`--verify-inventory`**), **remote automation** (**`ssh_node`**, **`python3 -m fiwicontrol.commands`** to bring up rigs), and **programmable power / USB paths** (**`fiwicontrol.power`**) so sequences are **scripted and checkable** before the PCIe harness runs. Longer term, **SPC** (below) is meant for **many hot-plug cycles**—spotting drift in failure rates or side metrics—not only general Fi‑Wi bring-up.
 
-**Immediate roadmap:** a **fleet of Raspberry Pi 5** boards as the primary **lab rig controllers** (remote **`fiwicontrol`** install, discovery over SSH, PCIe / Fi‑Wi harness hosts—docs and examples already assume Pi-class rigs), running **iperf 2** for **synthetic traffic** during network and bring-up experiments. Next: **ESP32** integration for **telemetry** (sensors, counters, rig health alongside those runs) and expanded **ush** orchestration alongside OpenSSH—not only the **`ush`** transport already wired through **`ssh_node`**, but first-class tooling for benches that standardize on **ush**. Beyond today’s Pi-oriented install path, **`ssh_node`** **`ush`** transport, and inventory/CLI stack, the rest is still roadmap.
+## Lab fleet: Raspberry Pi 5 and iperf 2 (planned)
 
-**Product differentiation:** we expect **advanced telemetry** and **advanced use of iperf 2**—load and measurement patterns tied to rig state, inventory, and (eventually) SPC, not only ad hoc throughput runs—to help **differentiate** Umber Fi‑Wi products in the market.
+We expect a **fleet of Raspberry Pi 5** boards as the primary **lab rig controllers**: remote **`fiwicontrol`** install, discovery over SSH, PCIe / Fi‑Wi harness hosts (docs already assume Pi-class rigs). Those Pi 5s will run **iperf 2** as **synthetic traffic** endpoints—controlled load and measurement during Fi‑Wi and bring-up experiments, not one-off manual runs. **None of this is automated in-repo yet** beyond what you can already drive by hand over **`ssh_node`**; first-class orchestration and reporting are roadmap.
+
+## ESP32, IEEE 802.11, and advanced telemetry (planned)
+
+Separately from the Pi 5 **`iperf`** plane, we plan **ESP32**-based nodes for **advanced telemetry**, including rich use of **IEEE 802.11 (Wi‑Fi)**: airlink statistics, channel / PHY-adjacent metrics, retries, timing, and correlation with harness and inventory state. The goal is lab- and field-grade **802.11 telemetry**, not only GPIO or serial counters. **This stack is not implemented yet** in **`fiwicontrol`**; today’s code is still the commands / lab / power packages above.
+
+## `ush` expansion (planned)
+
+Expanded **ush** orchestration alongside OpenSSH—not only the **`ush`** transport already wired through **`ssh_node`**, but first-class tooling for benches that standardize on **ush**. Roadmap only beyond today’s transport path.
+
+## Product differentiation
+
+We expect **advanced telemetry** (including **802.11**-centric ESP32 data) and **advanced use of iperf 2 on Raspberry Pi 5** hosts—patterns **tied to rig state, inventory, and (eventually) SPC**, not ad hoc throughput screenshots—to help **differentiate** Umber Fi‑Wi products in the market.
 
 ## Statistical process control (planned)