diff --git a/conformance/tests/l2-behavioral/vm-default-deny/chainsaw-test.yaml b/conformance/tests/l2-behavioral/vm-default-deny/chainsaw-test.yaml
index 0e72074..b3e7283 100644
--- a/conformance/tests/l2-behavioral/vm-default-deny/chainsaw-test.yaml
+++ b/conformance/tests/l2-behavioral/vm-default-deny/chainsaw-test.yaml
@@ -13,11 +13,16 @@
 #       podSelector:{} NetworkPolicy covers it). R-NET-01 for IaaS.
 #
 # METHOD (virtctl-free): the VM's ROOT is a CDI DataVolume on Longhorn (a mounted
-# PVC — NOT an ephemeral containerDisk, whose boot path is broken on this k3s cluster:
-# KubeVirt v1.9 serves the container-disk binary via a k8s `image` volume gated by the
-# ALPHA `ImageVolume` feature gate, disabled on k3s v1.31, so the apiserver prunes it
-# and the guest dies at OCI init. DataVolume roots bypass that path and are the
-# spec-required disk model — docs/06). cloud-init runs the two probes and writes a
+# PVC — NOT an ephemeral containerDisk), the spec-required, rebuild-surviving disk model
+# for VMs (docs/06, R-STATE-01), matching fixtures/vm.yaml. (Feature-gate note,
+# revalidated 2026-08: an earlier revision said the containerDisk boot path was broken on
+# this cluster — KubeVirt v1.9 serves the container-disk binary via a k8s `image` volume
+# gated by the ALPHA `ImageVolume` feature gate, which k3s v1.31 had DISABLED, so the
+# apiserver pruned it and the guest died at OCI init. That premise is now STALE: the
+# cluster is k3s v1.36.4, where ImageVolume is ENABLED by default
+# (kubernetes_feature_enabled{name="ImageVolume"}=1; a server-side dry-run RETAINS an
+# `image` volume rather than pruning it), so containerDisk roots would boot — DataVolume
+# is kept because it is the rebuild-surviving model.) cloud-init runs the two probes and writes a
 # PASS/FAIL verdict to a raw Longhorn block disk, then powers off (RerunOnFailure =>
 # stays down). A busybox reader pod reads the verdict back. The container default-deny
 # test proves the datapath fail-closed (default-deny-failclosed, L3); this asserts
diff --git a/conformance/tests/l2-behavioral/vm-lifecycle/chainsaw-test.yaml b/conformance/tests/l2-behavioral/vm-lifecycle/chainsaw-test.yaml
index 3042395..a249e00 100644
--- a/conformance/tests/l2-behavioral/vm-lifecycle/chainsaw-test.yaml
+++ b/conformance/tests/l2-behavioral/vm-lifecycle/chainsaw-test.yaml
@@ -21,19 +21,25 @@
 # (hermetic).
 #
 # DISK MODEL — CDI DataVolume on Longhorn (NOT an ephemeral containerDisk):
-#   KubeVirt v1.9 supplies the container-disk binary to the `volumerootdisk` init
-#   container via a Kubernetes-native `image` volume (VolumeSource.Image) mounted at
-#   /container-disk-binary. That k8s feature is gated by the ALPHA `ImageVolume`
-#   feature gate, which is DISABLED on this k3s v1.31 cluster — so the apiserver
-#   silently PRUNES the image volume + its mount, the binary is never present, and a
-#   containerDisk VM dies at OCI init with:
-#     exec: "/container-disk-binary/usr/bin/container-disk": no such file or directory
-#   A DataVolume-backed root is a mounted Longhorn PVC (CDI imports the same Fedora
-#   image into it out-of-band via its importer pod) and therefore does NOT touch the
-#   container-disk binary / image-volume path at all — it boots on this cluster. It is
-#   also the disk model the SPEC requires for VMs (docs/06, R-STATE-01: Longhorn-backed
-#   disks that survive rebuild), so this mirrors the representative fixtures/vm.yaml.
-#   Cost: a one-time CDI import per run (covered by the raised exec timeout below).
+#   The SPEC requires VMs to use Longhorn-backed disks that survive rebuild (docs/06,
+#   R-STATE-01), so this test — like fixtures/vm.yaml and the L3 vm-data-survival partner
+#   — boots from a CDI DataVolume on a Longhorn PVC (CDI imports the Fedora image into it
+#   out-of-band via its importer pod, so the VM never touches the container-disk binary /
+#   image-volume path). Cost: a one-time CDI import per run (covered by the raised exec
+#   timeout below).
+#   FEATURE-GATE NOTE (revalidated 2026-08 — the original "containerDisk is broken here"
+#   rationale is now STALE): KubeVirt v1.9 supplies the container-disk binary to the
+#   `volumerootdisk` init container via a Kubernetes-native `image` volume
+#   (VolumeSource.Image) mounted at /container-disk-binary, gated by the `ImageVolume`
+#   feature gate. On the ORIGINAL k3s v1.31 cluster that ALPHA gate was DISABLED, so the
+#   apiserver silently PRUNED the image volume + its mount and a containerDisk VM died at
+#   OCI init ("/container-disk-binary/usr/bin/container-disk: no such file or directory").
+#   The cluster is now k3s v1.36.4, where ImageVolume is ENABLED by default
+#   (kubernetes_feature_enabled{name="ImageVolume"}=1; a server-side dry-run of a Pod with
+#   an `image` volume RETAINS the volume + mount instead of pruning them). containerDisk
+#   roots would therefore boot on this cluster now — but DataVolume is retained regardless,
+#   because only it (not an ephemeral containerDisk) is the rebuild-surviving, spec-required
+#   disk model.
 # =============================================================================
 apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
diff --git a/conformance/tests/l3-fault-injection/vm-data-survival/chainsaw-test.yaml b/conformance/tests/l3-fault-injection/vm-data-survival/chainsaw-test.yaml
index 853f0cd..ceaa980 100644
--- a/conformance/tests/l3-fault-injection/vm-data-survival/chainsaw-test.yaml
+++ b/conformance/tests/l3-fault-injection/vm-data-survival/chainsaw-test.yaml
@@ -11,12 +11,19 @@
 #       (R-STATE-01 covers PaaS + IaaS).
 #
 # METHOD (virtctl-free, filesystem-agnostic, deterministic): a VM whose ROOT is a
-# CDI DataVolume on Longhorn (a mounted PVC — NOT an ephemeral containerDisk; the
-# containerDisk boot path is broken on this k3s cluster because KubeVirt v1.9 serves
-# the container-disk binary through a k8s `image` volume gated by the ALPHA
-# `ImageVolume` feature gate, which k3s v1.31 has disabled → the apiserver prunes the
-# volume and the guest dies at OCI init. DataVolume disks bypass that path and are the
-# spec-required disk model anyway — docs/06/R-STATE-01). The VM also has a SECOND
+# CDI DataVolume on Longhorn (a mounted PVC — NOT an ephemeral containerDisk). A
+# containerDisk root is EPHEMERAL — discarded when the VM is destroyed — so it could
+# never prove data-survival; the spec-required disk model here is a Longhorn-backed
+# DataVolume that OUTLIVES the VM (docs/06/R-STATE-01), which is exactly what this test
+# destroys-and-rebuilds. (Feature-gate note, revalidated 2026-08: an earlier revision
+# of this comment also claimed the containerDisk BOOT path was broken on this cluster —
+# KubeVirt v1.9 serves the container-disk binary through a k8s `image` volume gated by
+# the ALPHA `ImageVolume` feature gate, which k3s v1.31 had DISABLED, so the apiserver
+# pruned the volume and the guest died at OCI init. That premise is now STALE: the
+# cluster is k3s v1.36.4, where ImageVolume is ENABLED by default
+# (kubernetes_feature_enabled{name="ImageVolume"}=1; a server-side dry-run RETAINS an
+# `image` volume rather than pruning it), so containerDisk roots would boot — DataVolume
+# is used purely because only it survives rebuild.) The VM also has a SECOND
 # Longhorn BLOCK data disk; cloud-init writes a unique canary to that raw block device
 # and powers the guest off; runStrategy RerunOnFailure means
 # a clean shutdown STAYS down (VMI -> Succeeded), so the write is known-complete and