diff --git a/docs/ARCHITECTURE.md b/docs/ARCHITECTURE.md
index 9dc4614..b0601b9 100644
--- a/docs/ARCHITECTURE.md
+++ b/docs/ARCHITECTURE.md
@@ -179,26 +179,43 @@ rewrite: the seam stays visible even while the process is one.
 
 ## Display contract
 
-Three display paths, in two classes:
-
-**Class A — video out.** A screen driven directly by the Orin over SPI/DP/HDMI.
-The renderer is a local process subscribing to the bus over loopback.
-
-**Class B — data only.** The Orin sends no video, only data; the device renders
-itself.
+**Every display is data-only.** The Orin sends no video to anything. Each device
+subscribes to the bus and renders itself.
 
 | Path | Transport | Notes |
 |---|---|---|
-| Android app | WiFi, or USB (RNDIS) | Full-featured client, richest UI |
-| ESP32 + RLCD/e-ink | WiFi, or USB/BT serial | Low-rate, glanceable subset of signals |
+| `app-flutter` | USB (RNDIS), or WiFi | The display. Full client, richest UI, also the audio sink |
+| `app-esp32` + RLCD/e-ink | WiFi, or USB/BT serial | Low-rate glanceable subset. Not in current scope |
 
-Class B devices reaching the bus over IP connect to the broker directly. For
-transports without IP (BT SPP, plain USB serial), `telemetry-gw` bridges
-serial ↔ bus rather than each device inventing its own protocol.
+Displays reaching the bus over IP connect to the broker through `svc-gw`, which
+owns the boundary. For transports without IP — BT SPP, plain USB serial —
+`svc-gw` bridges serial ↔ bus rather than each device inventing its own protocol.
 
-Because both classes are bus subscribers, adding, removing or swapping a display
+Because every display is a bus subscriber, adding, removing or swapping one
 touches no acquisition code.
 
+### Video out was dropped
+
+An earlier revision had a second class: a screen driven directly by the Orin over
+SPI/DP/HDMI, rendered by a local process. It is gone, and with it `app-hud`.
+
+The reasoning, in order:
+
+- **No connector-powered display exists.** DisplayPort's `DP_PWR` supplies 3.3 V
+  at 500 mA — and VESA-compliant cables deliberately leave it unconnected at the
+  sink. HDMI's +5 V pin gives 55 mA. A panel needs 5–15 W. So a directly-driven
+  screen always needs its own power feed, which is the cable the removable display
+  unit was meant to avoid.
+- **DSI is not available.** The Orin Nano module carries DSI on SODIMM pins, but
+  the developer kit's carrier board does not break them out; DisplayPort is its
+  only display output. DSI would require a custom carrier board.
+- **It bought nothing the browser-shaped path does not.** A data-only client on
+  one USB cable is simpler, and the display unit stays swappable.
+
+Video out is what generated the enclosure, power and cabling complexity this
+project started out trying to solve. Removing it removed the problem rather than
+solving it.
+
 ## Navigation
 
 Self-hosted and offline-first, rather than a cloud maps SDK. Japan has good LTE
@@ -309,3 +326,4 @@ rewriting the document.
 | 17 | `svc-gw` combines local hub and app gateway; no client may block the hub | Accepted | 2026-09-03 |
 | 18 | Stubs publish the real topic and schema, never a fixture-specific one | Accepted | 2026-09-03 |
 | 19 | Services mock themselves behind their own input interface; no separate stub implementations exist | Accepted | 2026-09-04 |
+| 20 | Video out (Class A) dropped; every display is data-only. `app-hud` cancelled | Accepted | 2026-09-04 |
diff --git a/docs/REPOS.md b/docs/REPOS.md
index d2c185c..885b075 100644
--- a/docs/REPOS.md
+++ b/docs/REPOS.md
@@ -35,7 +35,6 @@ contracts repo, not copied into each consumer.
 | `contracts` | Topic namespace, payload schemas, Z27AG DBC | Consumed by every other repo, including non-Jetson clients; must not be duplicated |
 | `svc-core` | Acquisition + processing cluster: `can-bridge`, `obd-poller`, `gnss`, `decoder`, `recorder` | Developed and deployed as one unit on the Orin |
 | `app-esp32` | ESP32 RLCD/e-ink display firmware (Class B) | Embedded toolchain, flashed not deployed |
-| `app-hud` | Local renderer for a directly-driven screen (Class A) | Its own toolchain and graphics stack — **in question**, see the display contract |
 | `tool-analysis` | Offline session analysis, reverse-engineering notebooks | Runs off-car, no runtime coupling |
 
 Create these lazily — when there is something to put in them, not before.
diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md
index f27ff6c..0bd8e15 100644
--- a/docs/ROADMAP.md
+++ b/docs/ROADMAP.md
@@ -55,10 +55,12 @@ provides a cross-check for reverse-engineered ones.
 
 Order chosen by feedback speed, not ambition.
 
-- [ ] One display end-to-end first, proving the contract — Android client is the
-      quickest to iterate on
-- [ ] `app-hud` — directly-driven screen (Class A)
-- [ ] `app-esp32` — RLCD/e-ink glanceable subset (Class B)
+- [ ] One display end-to-end first, proving the contract — `app-flutter` is the
+      quickest to iterate on, and is the only display in current scope
+- [ ] `app-esp32` — RLCD/e-ink glanceable subset. Deferred, no hardware in scope
+
+Video out was dropped along with `app-hud`; see the display contract in
+[ARCHITECTURE.md](ARCHITECTURE.md#display-contract).
 
 ## Phase 5 — Camera and inference · *separate task*