diff --git a/phase8_iteration16_close.md b/phase8_iteration16_close.md
new file mode 100644
index 0000000..beb05f6
--- /dev/null
+++ b/phase8_iteration16_close.md
@@ -0,0 +1,95 @@
+# Iteration 16 — Phase 8 (close)
+
+Closes 2026-05-14. iter16 = α-16 OUTPUT byte verification on VP8 + consolidation of Bug 4/5/6 cause-class. PARTIAL close. No code changes; pure narrowing.
+
+## Outcome
+
+Bug 6 (VP8 libva partial output, hash `bcc57ed5…`) verified via the same α-16 methodology applied to HEVC at iter14:
+
+```
+libva VP8 frame 1 OUTPUT dump:    300614 bytes
+input IVF frame 1 size:           300624 bytes  (+10-byte VP8 uncompressed header)
+
+Byte-identity check with +10 offset (stripping VP8 uncompressed header):
+  0 bytes differ
+```
+
+VAAPI consumer (ffmpeg-vaapi) parses the VP8 uncompressed header client-side and forwards only the compressed first-partition bytes onward. libva backend writes those bytes to OUTPUT buffer, byte-identical to what kdirect would write.
+
+## Bug 4 + Bug 5 + Bug 6 = same cause class
+
+Cumulative verification across iter8–iter16:
+
+| Bug | Codec | libva controls (rkvdec-read fields) | libva OUTPUT bytes | Result |
+|---|---|---|---|---|
+| Bug 4 | H.264 | byte-equal to kdirect (10 fields verified) | byte-identical to input slice NAL | partial 16×32 leak |
+| Bug 5 | HEVC | byte-equal to kdirect (every rkvdec-read SPS/PPS/slice/decode_params field) | byte-identical to input IDR NAL | all-zero |
+| Bug 6 | VP8 | (similar pattern; controls + OUTPUT verified by α-16 here) | byte-identical to input frame minus uncompressed header | 74.8% zero with partial real bytes |
+
+**All three bugs are kernel-side rkvdec / hantro failures specific to how the driver processes libva's V4L2 ioctl sequence on these per-codec paths.** VP9 + MPEG-2 work via the same libva backend on the same hardware, ruling out a categorical libva problem.
+
+## What libva has shipped through iter8–iter16 (cumulative)
+
+8 wire-correctness or diagnostic commits, all zero-regression:
+
+| iter | Commit | Description |
+|---|---|---|
+| 8 | `7eae6ea` | γ env-gated CAPTURE buffer dump |
+| 8 | `66ecbef` | IMP-1 env-gated CAPTURE pre-zero diagnostic |
+| 8 | `6f4e583` | stdlib.h fix-forward |
+| 8 | `0226684` | α-2: pass H.264 POC values through unchanged |
+| 9 | `e0be4e6` | α-7: per-context monotonic timestamp counter |
+| 11 | `8e2c04f` | α-13 + α-14: HEVC SPS reorder_pics + IRAP/IDR flags |
+| 13 | `ca4dd88` | α-17: DMA_BUF_IOCTL_SYNC around CAPTURE read |
+| 14 | `522fb6d` | α-16: env-gated OUTPUT byte dump |
+| 15 | `3760a70` | α-19: explicit S_FMT CAPTURE |
+
+Plus campaign infrastructure for diagnostic instrumentation (env-gated dumps for both CAPTURE post-DQBUF and OUTPUT pre-QBUF).
+
+## What's shipped at the kernel level
+
+Kernel substrate `linux-fresnel-fourier 7.0-1` → `7.0-2` (iter12):
+- 3 RFC v2 vb2_dma_resv producer fence patches integrated.
+- Compositor / explicit-sync consumers benefit from real dma_resv fences.
+- Libva pixel readback path is orthogonal — unchanged.
+
+## Campaign-level scoreboard
+
+```
+Codec   | Site      | Status        | libva-side state | Kernel-side root cause
+========|===========|===============|=============|====================================
+H.264   | rkvdec    | PARTIAL       | byte-correct | Bug 4 (kernel HEVC + H.264 paths
+HEVC    | rkvdec    | DEGRADED *    | byte-correct |   produce wrong/zero output via
+VP9     | rkvdec    | PASS direct   | works        |   libva's particular ioctl pattern,
+MPEG-2  | hantro    | PASS (env)    | works        |   work via kdirect's pattern)
+VP8     | hantro    | PARTIAL (env) | byte-correct | Bug 6 (kernel hantro VP8 partial)
+```
+
+VP9 + MPEG-2 are direct passes via libva. H.264 / HEVC / VP8 reach the kernel correctly from libva, but the kernel produces wrong output for libva's pattern (works for kdirect).
+
+## Memory rule already saved
+
+`feedback_libva_byte_correct_kernel_bug.md` was saved at iter14 close. iter16 confirms the rule extends to Bug 6 (VP8). The rule is now codec-agnostic for HEVC + H.264 + VP8 (and presumably any other libva-failing codec on this kernel).
+
+## iter17+ candidates (ordered)
+
+1. **kernel-side rkvdec hot-path trace** — read RK3399 rkvdec source carefully; instrument via ftrace / eBPF kprobe; compare what kernel state evolves for the same bitstream when libva vs kdirect triggers decode. **Heaviest investment.** Route via kernel-agent.
+
+2. **Pivot to iter4-B1b backlog** — multi-decoder routing in libva backend (RK3399 has rkvdec for H.264/HEVC/VP9, hantro for MPEG-2/VP8). One backend instance routes per codec to the right /dev/media*. Architectural refactor, ~200-400 LOC, no kernel work.
+
+3. **Re-anchor regression baselines** — codify the 5 stable hashes as a regression test suite in the fork's CI infrastructure (if any).
+
+4. **Campaign close-out / handoff documentation** — long-form deliverable describing the libva backend's byte-correctness, the kernel-side gap, and what would need to land upstream / in mainline rkvdec for Bug 4/5/6 closure.
+
+The iter17 productive direction is kernel-side investigation. Per `feedback-libva-byte-correct-kernel-bug`, libva-side changes are now confirmed inert for these bugs.
+
+## Substrate state at iter16 close
+
+- Fork tip `3760a70` on noether + fresnel + gitea (unchanged from iter15).
+- Backend SHA `c1d4bb53…` on fresnel.
+- Kernel `7.0-2`.
+- 5-codec anchors preserved.
+
+## Iter16 contribution
+
+Just an empirical confirmation that Bug 6 is in the same cause class as Bug 4/5. No code changes. The OUTPUT byte verification methodology generalizes cleanly across codecs.