diff --git a/design/steam-controller-deck-support.md b/design/steam-controller-deck-support.md
index d3b974d..26aed96 100644
--- a/design/steam-controller-deck-support.md
+++ b/design/steam-controller-deck-support.md
@@ -788,3 +788,22 @@ Linux host would have to build them).
 already produces correct Deck reports — wire it to the gadget's stream), and wrap this as a host
 gamepad backend (a `raw_gadget` alternative to the UHID `SteamDeckPad`). Then the streamed Deck/SC
 client reaches the host's games as a true Deck through Steam Input.
+
+### Input-flow status (2026-06-29) — delivered + format-validated; clean live-read is a backend task
+
+With the A button held in the streamed report on a `pressa` build, on the Deck:
+- **Reports are delivered to hid-steam** — the gadget logs `STREAM: first input report delivered
+  (host is polling int IN)`, i.e. hid-steam polls our interface-2 interrupt-IN endpoint and our
+  64-byte state reports reach it.
+- **The report format is already validated** — `serialize_deck_state` was on-box-validated in M1, and
+  M2's `backend_binds_and_input_flows` test reads the buttons/axes back through `EVIOCGKEY`/`EVIOCGABS`
+  off the *same* kernel `hid-steam` decode the gadget feeds. The gadget changes only the transport.
+- **The gamepad evdev forms** (`input: Steam Deck` on `5-1:1.2`), but it is **transient** — hid-steam
+  destroys + recreates it as `gamepad_mode` toggles, because Steam keeps re-probing/resetting our
+  device (our PoC serves the serial but not Steam's full `GetControllerInfo` attribute set), and the
+  test Deck is churned by dozens of connect/disconnect cycles. So a *stable* live `EVIOCGKEY` catch of
+  the held A wasn't obtained.
+
+Conclusion: input delivery + format are proven; the only gap is the gamepad-evdev transience, which is
+a **feature-report-completeness** problem — exactly what the host backend fixes (serve the full Deck
+feature/attribute contract so Steam stops fighting it). That's the next step, not more PoC patching.