diff --git a/docs/re/audio-capture-channel-map-trap.md b/docs/re/audio-capture-channel-map-trap.md
index 7a29addf..e66342b0 100644
--- a/docs/re/audio-capture-channel-map-trap.md
+++ b/docs/re/audio-capture-channel-map-trap.md
@@ -49,6 +49,25 @@ map given to `parec` explicitly:
 
 No duplicates. **CONTROL PASSED.**
 
+## 🔴 And a LEVEL CHECK cannot see this failure — by construction
+
+The port made this point while building a checker for it, and it refutes
+something written above.
+
+In the known-bad control, **all six channels report a peak of −18.063656 dB,
+identical to six decimals, while the file contains three duplicate pairs.** Equal
+tone amplitudes make the peak table uniform no matter how the channels are
+permuted or duplicated — and on *real* content the peaks simply differ from each
+other, which looks equally healthy. Either way the table is uninformative.
+
+⚠️ So "the WAV has plausible per-channel levels" was not weak evidence that the
+capture was sound; it was **no** evidence, and this page said otherwise. The
+per-channel peak table is the natural thing to eyeball after a capture and it is
+**blind to remap corruption**. What detects it is hashing each channel and
+comparing — the port's `tools/port/check-capture`, controlled in both directions
+(six distinct tones → PASS; this page's known-bad pattern → FAIL naming all four
+pairs; the withdrawn capture → FAIL on `ch2 == ch5`).
+
 ## The rule
 
 ⚠️ **A null sink whose `channel_map` differs from the client's makes PulseAudio