diff --git a/phase7_iter39_close.md b/phase7_iter39_close.md
index fa6a7c2..1b3dda3 100644
--- a/phase7_iter39_close.md
+++ b/phase7_iter39_close.md
@@ -65,3 +65,15 @@ Both pushed to gitea master.
 1. **Real Main10 fixture acquisition** — without a properly-encoded Main10 HEVC sample, the Main10 path can't be empirically verified. Once a fixture is available the same test script (`phase7_iter39_test_rig.sh`) covers it; verification is a 5-minute run.
 2. **Re-test iter39 on ampere (RK3588)** — vpu981 is supposed to support 10-bit decode properly. If iter39 PASSes on ampere it's a strong signal the backend is right and the fresnel result is purely a kernel/HW issue.
 3. **Memory entry** filed (see above).
+
+## Phase 7 Option B implementation (post-close addendum)
+
+User-directed Option B applied 2026-05-17 evening after cross-test on ampere:
+
+- **Web research** (lwn.net/Articles/950434, patchwork.kernel.org Karlman v6→v10 series) showed: kernel + HW ready; ffmpeg-v4l2-request userspace plumbing for the new uAPI controls is the missing piece. Karlman's series explicitly states "FFmpeg patches required to fully runtime test."
+- **Cross-test on ampere (RK3588)**: same all-zero failure mode as fresnel. kdirect ALSO returns EINVAL on both SoCs. Confirms the gap is in upstream ffmpeg userspace, not our backend or device-specific HW.
+- **Backend commit `6bc12fe`** drops `VAProfileH264High10` + `VAProfileHEVCMain10` from `RequestQueryConfigProfiles`. All other iter39 backend code (codec.c, context.c, image.c, surface.c, nv15.c, request.h is_10bit flag) is RETAINED — re-enable by uncommenting two `profiles[index++]` lines and bumping the H264 guard from `(-5)` back to `(-6)` when upstream ffmpeg-v4l2request learns Hi10P.
+
+vainfo post-Option-B: 10 profiles on fresnel (matches iter38 baseline exactly). 9 profiles on ampere (matches ampere-fourier iter1 — no VP9 on vpu981 path).
+
+iter38 5/5 PASS preserved on fresnel post-Option-B (no other codec touched). Cross-device cleanliness maintained.