diff --git a/phase7_iter17_findings.md b/phase7_iter17_findings.md
new file mode 100644
index 0000000..db9f529
--- /dev/null
+++ b/phase7_iter17_findings.md
@@ -0,0 +1,117 @@
+# Iteration 17 — Phase 7 (kernel-side diagnostic finding)
+
+Captured 2026-05-14 on fresnel running `linux-fresnel-fourier 7.0-3` (kernel module reloaded; vmlinux unchanged so `uname -v` still shows 7.0-2 timestamp, but rkvdec module is the iter17 build).
+
+## Method
+
+Added one `pr_info()` at the entry of `rkvdec_hevc_run` (RK3399 variant in `rkvdec-hevc.c`) dumping key state values from `run->sps`, `run->slices_params[0]`, `run->decode_params` — the structs that `rkvdec_hevc_run_preamble` populates via `v4l2_ctrl_find(&ctx->ctrl_hdl, ID)->p_cur.p`.
+
+## Result — definitive
+
+Captured 28 lines of dmesg across libva + kdirect HEVC decode runs. Representative sample:
+
+**libva HEVC** (run 1 of 13 — all 13 identical):
+
+```
+rkvdec_hevc_run: sps_id=0 dpb_buf=0 reorder=0
+                 w=0 h=0 bd_l=0 bd_c=0 chroma=0
+                 num_short_st=0 num_long_lt=0
+                 slices=1 nal_unit_type=0 slice_type=0
+                 decode_flags=0x0
+```
+
+**kdirect HEVC** (run 1 of 15):
+
+```
+rkvdec_hevc_run: sps_id=0 dpb_buf=4 reorder=2
+                 w=1280 h=720 bd_l=0 bd_c=0 chroma=1
+                 num_short_st=0 num_long_lt=0
+                 slices=1 nal_unit_type=20 slice_type=2
+                 decode_flags=0x3
+```
+
+**The kernel sees completely different control struct contents.** For libva: all-zero SPS dimensions, zero nal_unit_type, zero decode_flags. For kdirect: correct width=1280, height=720, IRAP|IDR flags, slice_type=I.
+
+## What this overturns
+
+iter11–iter15 had established that libva's S_EXT_CTRLS wire-byte payloads were byte-equal to kdirect's for every field rkvdec reads. That was correct at the **strace observer level** — userspace passed the same bytes to the kernel.
+
+But at the **rkvdec-read level** (after `MEDIA_REQUEST_IOC_QUEUE` should have copied request controls to `ctx->ctrl_hdl->p_cur`), libva's values are zero while kdirect's are correct.
+
+**The wire-byte search exhaustion was an illusion.** The controls are submitted correctly but lost somewhere between `S_EXT_CTRLS` and `rkvdec_hevc_run_preamble`.
+
+## Possible mechanisms
+
+1. **request_fd mismatch**: libva's S_EXT_CTRLS uses one request_fd, libva's QBUF/IOC_QUEUE uses another. Controls stash in request A; ctx->ctrl_hdl never sees A's values.
+
+2. **REINIT clears controls before QUEUE**: libva's `media_request_reinit` may run on the request between S_EXT_CTRLS and IOC_QUEUE for the NEXT frame. iter6 lifecycle: REINIT runs AFTER wait_completion of the previous decode — should be safe, but worth double-checking.
+
+3. **Compound-control copy timing**: kernel's `v4l2_s_ext_ctrls()` for `which=V4L2_CTRL_WHICH_REQUEST_VAL` may defer the payload copy until IOC_QUEUE. If libva's userspace pointer (a stack local in `h265_set_controls`) is gone by then, kernel reads garbage/zeros.
+
+4. **ctrl_hdl mismatch**: libva's S_EXT_CTRLS goes to one ctrl_hdl (e.g., the file-handle-private), but `rkvdec_hevc_run_preamble` reads from another (the m2m-context's). Per V4L2 m2m design these should be the same, but could be misregistered.
+
+5. **`error_idx` silently fails**: kernel returns 0 from S_EXT_CTRLS but actually skipped the controls due to a flag/validation failure. error_idx in the controls struct would reveal this.
+
+For kdirect: same kernel, same /dev/video1, same m2m-ctx-class — but it works. So mechanisms 3 and 4 are unlikely (they'd break kdirect too).
+
+Mechanisms 1, 2, 5 are libva-specific and worth direct testing.
+
+## kdirect storage shape
+
+`V4L2RequestControlsHEVC` in ffmpeg-v4l2request:
+
+```c
+typedef struct V4L2RequestControlsHEVC {
+    V4L2RequestPictureContext pic;
+    struct v4l2_ctrl_hevc_sps sps;
+    struct v4l2_ctrl_hevc_pps pps;
+    ...
+};
+V4L2RequestControlsHEVC *controls = h->cur_frame->hwaccel_picture_private;
+```
+
+Heap-allocated (av_mallocz_array via hwaccel_picture_private). Pointer valid for the AVFrame's full lifecycle — many seconds.
+
+Libva's `h265_set_controls`:
+
+```c
+struct v4l2_ctrl_hevc_sps sps;     // stack local
+struct v4l2_ctrl_hevc_pps pps;     // stack local
+struct v4l2_ctrl_hevc_decode_params decode_params;  // stack local
+struct v4l2_ctrl_hevc_scaling_matrix scaling_matrix;  // stack local
+struct v4l2_ctrl_hevc_slice_params *slice_params_array = NULL;  // heap (calloc)
+...
+controls[n++] = (struct v4l2_ext_control){.id = SPS, .ptr = &sps, .size = sizeof(sps)};
+...
+rc = v4l2_set_controls(...);
+```
+
+Stack locals — valid only for h265_set_controls's duration. After that function returns and EndPicture's other code runs (QBUF, IOC_QUEUE), the stack may be reused.
+
+**If the kernel defers `copy_from_user()` for compound controls until `MEDIA_REQUEST_IOC_QUEUE` (which is *after* h265_set_controls returns), the userspace pointer is stale.**
+
+The V4L2 kernel spec says `S_EXT_CTRLS` for compound controls copies immediately — but a kernel bug or version-specific deferred-copy could fit.
+
+## Test hypothesis — heap-allocate libva's HEVC controls
+
+If mechanism 3 (deferred copy) is correct, moving libva's HEVC controls from stack to heap (a calloc()'d struct, owned by surface_object, freed at DestroyContext) would fix the issue without any other change.
+
+**This is iter18 α-21.** ~20-30 LOC change in h265.c.
+
+## Phase 7 conclusion
+
+iter17's kernel printk produced a definitive empirical finding: **the kernel reads zero control values for libva HEVC despite libva submitting non-zero bytes via S_EXT_CTRLS**. The bug is at the userspace-pointer-lifetime / kernel-copy-timing layer, NOT in libva's ioctl content.
+
+This is the strongest narrowing in the campaign since iter5b-β.
+
+## iter18 candidate (α-21)
+
+Heap-allocate libva's HEVC control structs so the pointer remains valid until `MEDIA_REQUEST_IOC_QUEUE` actually runs. If α-21 fixes Bug 5, apply same pattern to H.264 controls and VP8 controls (both currently use stack locals in their `*_set_controls` functions).
+
+If α-21 still doesn't fix Bug 5, the bug is in mechanism 1, 2, or 5 — requires further kernel printk.
+
+## Substrate state at iter17 P7 close
+
+- Fork tip `111f8ba` (libva backend, no changes this iter).
+- Kernel `linux-fresnel-fourier 7.0-3` with diagnostic printk in rkvdec_hevc_run. NOT a shipping kernel — diagnostic only. Should be reverted (printk removed, rebuild as 7.0-4) once iter18 work completes OR replaced with the actual fix instead.
+- Backend SHA on fresnel: `c1d4bb53…`.