diff --git a/phase8_iteration33_close.md b/phase8_iteration33_close.md
index 74306d2..89e038b 100644
--- a/phase8_iteration33_close.md
+++ b/phase8_iteration33_close.md
@@ -14,9 +14,11 @@ Unblock VP8 through libva backend → hantro. Pre-existing libva single-device p
 | HEVC 10F | PASS | 108f925bb6cbb6c9 |
 | VP9 10F | PASS | cf35908ae0f9ab60 |
 | **VP8 10F** | **PASS** (iter33 α-30) | d3231e5b6c0ee10b |
-| MPEG-2 10F | FAIL (separate bug) | libva=95c5905890c937d4 sw=933b744134e47ba4 |
+| MPEG-2 10F | PASS (libva==kdirect bit-exact) | libva=95c5905890c937d4 kdirect=95c5905890c937d4 |
 
-4 of 5 codecs PASS byte-equal SW.
+**5 of 5 codecs PASS** for the libva-correctness contract (libva backend output bit-equal to kdirect reference path).
+
+4 of 5 also bit-equal to SW reference. MPEG-2's HW decoder (hantro) differs from libavcodec SW MPEG-2 by ≤1 LSB per ~67 pixels (mean=0.01, max=1) — IDCT precision artifact, not a libva bug. Both libva and kdirect HW paths produce identical bytes through hantro.
 
 ### Root cause for VP8
 
@@ -66,9 +68,11 @@ VAAPI's `pic_fields.bits.key_frame` is INVERTED (0 = keyframe per VP8 spec conve
 
 Source: backend commit `7e0848d`.
 
-### MPEG-2 (surfaced, deferred to iter34)
+### MPEG-2 (closed in same iteration)
 
-Same libva → hantro path. Decodes to non-zero output but byte-different from SW for all 10 frames. Likely a similar ffmpeg-vaapi-strip / OUTPUT-mismatch as VP8, possibly with different offset semantics for MPEG-2. To investigate in next iteration.
+Surfaced as "fail" against SW, but libva-vs-kdirect comparison showed both HW paths produce BIT-EXACT EQUAL output (sha=95c5905890c937d4). MPEG-2 decode through libva works correctly. The HW-vs-SW byte divergence is a hantro IDCT precision difference vs libavcodec's exact IDCT (mean diff = 0.01 byte, max = 1 byte, ~1.5% of bytes nonzero). Not a libva bug, not a fixable bug at this level.
+
+No iter34 needed for MPEG-2.
 
 ### Substrate state at iter33 close