diff --git a/crates/pf-client-core/src/video.rs b/crates/pf-client-core/src/video.rs
index f936eed8..e6b295af 100644
--- a/crates/pf-client-core/src/video.rs
+++ b/crates/pf-client-core/src/video.rs
@@ -52,7 +52,7 @@
 //! | native D3D11VA | [`crate::video_d3d11_native`] | H.264, H.265 | **yes** — frame-hash parity on an RTX 4090 and an AMD iGPU + a 30-minute soak (M5), re-confirmed 250/250 (+ 50/50 Main 10) on an RTX 3500 Ada and an Intel Arc on 2026-08-07 |
 //! | native D3D11VA | | AV1 | **yes** — 250/250 delivered frames bit-identical to libavcodec on an RTX 3500 Ada AND an Intel Arc (2026-08-07). It got there from 186/250 and 245/250 DIVERGING frames on those same two GPUs: `plan_to_dxva_av1` released the picture this frame's own refresh displaces before assigning the decode target its slot, and `SlotMap::assign` hands back the slot just vacated — so 268 of the vector's 274 frames named one surface as both `CurrPicTextureIndex` and a `RefFrameMapTextureIndex` entry. Intel followed the aliased surface (structurally wrong from display frame 4); NVIDIA tolerated it until the `order_hint` wrap at 64 made one 16x24 luma block depend on it. ONE defect, two driver tolerances — the two unlike signatures were not two bugs. TWO vendors, still NO soak on the goldens: the 5-minute 4K60 soak this row used to cite measured throughput, and "streams cleanly" was true throughout the failure |
 //! | native VAAPI | [`crate::video_vaapi_native`] | AV1 | **not proven** — but it has now DECODED: 250/250 frames of the vendored AV1 vector on `.25` (Radeon 780M, RDNA3, Mesa 26.0.3) on 2026-08-07, NV12 on a tiled AMD modifier, and `probe_this_machines_libva` reports `AV1 Profile 0: VLD decode`. Never frame-hash parity-checked: the rung exports a tiled dmabuf with no CPU-readable image, so parity needs a readback path that does not exist yet |
-//! | native VAAPI | | H.264, H.265 | **NO** — these two legs have still never decoded a frame anywhere (M6/M7) |
+//! | native VAAPI | | H.264, H.265 (Main / Main 10) | **not proven** — but all three have now DECODED, on `.25` (Radeon 780M, RDNA3, radeonsi, Mesa 26.0.3, VA-API 1.23) on 2026-08-07: every access unit of the vendored H.264 (250), H.265 (250) and HEVC Main 10 (50) vectors was accepted with no decode error, NV12 for the 8-bit legs and **P010** for Main 10, all on the same tiled AMD modifier, and `probe_this_machines_libva` reports VLD decode for H.264 High, HEVC Main and HEVC Main 10. Delivered frame counts are 225/204/45 rather than 250/250/50, and that is the RUNG, not the driver: `finish` shows `outputs.last()` and never more, so an access unit that bumps several pictures out of the DPB shows the last and drops the rest, and nothing flushes the DPB at end of stream — a conformance vector reorders, punktfunk's zero-reorder host output never does. Never frame-hash parity-checked, for the same reason as AV1: the rung exports a tiled dmabuf with no CPU-readable image |
 //! | software | `video_software` | H.264, AV1 | **not proven** — openh264 has never run on glass; rav1d HAS now decoded 1080p and 4K60 AV1 there (2026-08-07, .21) and recovers in-session from a mid-stream reference loss, but with no parity check and no soak. Its 4K "abort" was never about 4K: rav1d 1.1.0 kills the process on ANY decode error while it holds a single frame context, so `video_software` opens it with two — see [`crate::video_software`] |
 //!
 //! The software rung's evidence is recorded for the same reason but does not gate
@@ -1146,11 +1146,13 @@ pub fn native_evidence(rung: NativeRung, wire: u8) -> RungEvidence {
              Intel Arc (2026-08-07), after fixing a decode target that aliased a reference \
              surface on 268 of 274 frames - two vendors, no soak (M7)",
         ),
-        // 2026-08-07: the VAAPI rung decoded its first frames ever — 250/250 of the vendored
-        // AV1 vector on `.25` (Radeon 780M, RDNA3, Mesa 26.0.3), NV12 on a tiled AMD
-        // modifier. So "never decoded a frame anywhere" is no longer true of AV1 and must not
-        // be printed for it; it is still exactly true of the other two legs, which is why
-        // this arm is now split.
+        // 2026-08-07: the VAAPI rung decoded its first frames ever, and by the end of that
+        // day ALL FOUR legs had — 250/250 of the vendored AV1 vector, then every access unit
+        // of the H.264 (250), H.265 (250) and HEVC Main 10 (50) vectors, on `.25` (Radeon
+        // 780M, RDNA3, Mesa 26.0.3): NV12 for the 8-bit legs, P010 for Main 10, all on a
+        // tiled AMD modifier. So "never decoded a frame anywhere" is no longer true of ANY of
+        // them and must not be printed. The arm stays split only because AV1's note carries
+        // its own frame count; both halves say the same thing about parity.
         //
         // Not `verified`, and for a reason the AV1 row above makes vivid: a rung can decode
         // 250 frames and still produce wrong pixels. Parity is what tells them apart, and
@@ -1164,8 +1166,10 @@ pub fn native_evidence(rung: NativeRung, wire: u8) -> RungEvidence {
         ),
         (NativeRung::Vaapi, _) => (
             false,
-            "NEVER decoded a frame on any hardware - the AV1 leg has now run on RDNA3, these \
-             two have not (M6/M7)",
+            "decoded every access unit of the vendored H.264, H.265 and HEVC Main 10 \
+             vectors on RDNA3 (Mesa 26.0.3, 2026-08-07) - their first frames on any \
+             hardware - but has never been frame-hash parity-checked: the rung exports \
+             a tiled dmabuf with no CPU-readable image (M6/M7)",
         ),
         // The 4K AV1 abort recorded here on 2026-08-07 is FIXED, and it was never about 4K.
         // rav1d 1.1.0 aborts the process on ANY decode error while it holds a single frame