re: run 'grep the corpus for the claim' on this corpus -- four still standing

Applying my own METHOD entry one iteration after writing it found four refuted
statements still asserted unmarked where a reader lands:

  * envelope correlation 'has no resolving power' -- in three places including
    HANDOFF. The port controlled the same estimator on a single track and got
    r=1.0000 at zero offset; the saturation needs CONCURRENT streams sharing
    timing. I agreed to this in a message and never landed it.
  * '8 of 10 three-chunk regions' -- still asserted in HANDOFF in a different
    section from its own correction.
  * 'r9 is a wild pointer, never a guest address' -- still asserted inside the
    kept-for-the-record section.
  * the ALSA channel permutation, stated without scope, when a later capture
    measured the identity and labelling from it put the silent channel on the
    wrong name.

All four marked in place, striking the sentence and pointing forward.

Two lessons added: a 'kept for the record' section still asserts, so labelling
the heading is not enough; and naming a refuted claim keeps it greppable, so the
audit returns its own corrections as hits and every hit needs reading.

The first item is the one worth admitting: I acknowledged that correction in a
message, wrote the entry about corrections that never land, and then did not land
my own for a full iteration.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/METHOD.md

@@ -1482,3 +1482,31 @@ inside the emulator and looked exactly like a dead pad.
 📌 Companion to the entry above about controls: a control proves your instrument
 reads correctly; a **delivery check** proves the experiment happened at all. They
 are different, and only the second one catches a null result that never ran.
+
+### The audit, run on this corpus — and I had already re-offended
+
+Applying *grep the corpus for the claim* to this repository, one iteration after
+writing it, found **four** refuted statements still standing unmarked at the point
+they are made:
+
+| claim | where | refuted by |
+|---|---|---|
+| envelope correlation "has no resolving power" | 3 places, incl. `HANDOFF.md` | the port's control: r = 1.0000 at zero offset on a single track — the saturation needs *concurrent* streams |
+| "8 of 10 three-chunk regions start mid-stream" | `HANDOFF.md`, in a *different* section from its correction | the completed census: 25 three-chunk, 17 affected |
+| "`r9` is a wild pointer… never a guest address" | `HANDOFF.md`, in the kept-for-the-record section | it is a *host* address; subtract `0x100000000` |
+| the ALSA channel permutation, stated without scope | `audio-capture-alsa-file-tee.md` | a later capture measured the **identity** |
+
+🔴 **The first is the one worth admitting.** The port corrected that claim, I agreed
+in a message, wrote the METHOD entry about corrections that never land — **and did
+not land my own, for a full iteration.** Acknowledging a correction in
+conversation feels like making it and is not.
+
+📌 Two things the audit itself teaches:
+
+* **A "kept for the record" section still asserts.** Labelling a section superseded
+  at its heading does not mark the sentence a reader lands on. Strike the sentence
+  and point forward from it.
+* **Naming a refuted claim keeps it greppable**, so the audit returns its own
+  corrections as hits. Every hit needs reading, not just counting — a grep verdict
+  alone sends you to re-fix what is already fixed. That is the price of not deleting
+  the old sentence, and it is worth paying.

docs/re/audio-capture-alsa-file-tee.md

@@ -33,6 +33,15 @@ channel `[0,1,4,5,2,3]` — i.e. `FL FR BL BR FC LFE` where the WAV file had
 `FL FR FC LFE BL BR`. Deterministic, invertible, and **not** data loss; do not
 mistake it for the remap corruption documented in the companion page.
 
+🔴 **But this permutation does NOT travel — measure it per capture.** It was
+measured on *this* chain, with these tones. A later Canary capture through the same
+recipe came out as the **identity**, and labelling its channels from this table put
+the silent channel on `BR` when it was `LFE`
+([`structures/intro-audio-decomposed.md`](structures/intro-audio-decomposed.md)).
+A 6×6 correlation against a known reference costs nothing and is **its own control**:
+if every row's maximum falls on a distinct source channel, the mapping is a genuine
+permutation and you have measured it rather than assumed it.
+
 ## The three configuration traps, in the order they bite
 
 1. **`ALSA_CONFIG_PATH` REPLACES the entire ALSA config.** Without

docs/re/data/adv-stream-assignment.txt

@@ -14,6 +14,10 @@
 #
 # 🔴 WHAT DID NOT WORK: envelope correlation cannot discriminate.
 # Every residual channel shares the dialogue's activity timing, so a
+# ⚠️ IN THIS REGIME ONLY (corrected 2026-08-30): the port controlled the same
+# estimator on a single dialogue track and got r=1.0000 at zero offset with
+# -0.08..+0.08 elsewhere -- it localises sharply. The saturation below needs
+# CONCURRENT streams sharing timing at zero lag. Not a general limit.
 # per-pair lag search returns 0.86-0.95 for EVERY chunk against EVERY
 # channel. Recorded because it looks like a strong result and is not.
 #

docs/re/structures/intro-audio-decomposed.md

@@ -114,11 +114,17 @@ The three chunks were dumped from the resolved voice region
 
 ### 🔴 Two instruments failed first, and both look convincing
 
-* **Envelope correlation cannot discriminate.** A per-pair lag search returns
+* **Envelope correlation cannot discriminate *here*.** A per-pair lag search returns
   **0.86–0.95 for every chunk against every channel**, because all six residual
   channels share the dialogue's activity timing. A number that high reads as a
-  result; it is the instrument having no resolving power. Recorded so nobody
-  reports it as one.
+  result; it is the instrument having no resolving power **in this regime**.
+  ⚠️ **Corrected 2026-08-30 — do not generalise this.** The port agent controlled
+  the same estimator on a single dialogue track and got **r = 1.0000 at zero offset
+  and −0.08…+0.08 everywhere else**: it localises sharply. The saturation here is
+  specific to **concurrent streams sharing timing at zero lag**, which a lag search
+  over one track never encounters. This page said it flatly for a day after that
+  correction was known, which is the failure `METHOD.md` calls *a correction that
+  does not reach the artifact*.
 * **Sample-level correlation returns ≈ 0.** The chunks do not start with the movie
   and the XMA decode's framing offset is unknown.