port: audit the remaining multi-leg claims -- the pattern I predicted is not there

I have listed 'four unaudited multi-leg claims' as open for several iterations and
said I expected the same inversion in them: a count standing in for an exclusion
argument. Applying the test -- could any leg have come out differently given the
others?

loop_start_why holds. Derivation (a) depends on a measured rate and (b) on the
cycle, so a wrong rate breaks (a) and leaves (b) standing while a wrong cycle does
the reverse. They fail independently, which is what 'two derivations' was
claiming. Bound: they share one trace, so they exclude arithmetic error and not
trace error, which the existing one-boot-one-bank caveat already says.

arithmetic_why holds. The corpus's 28.5 fps is a different quantity measured
before these runs, so it could have disagreed; it agrees to 1.4%. Corroboration
rather than restatement.

black_hold_why holds and needed nothing: it was already an exclusion argument -- a
constant excluded, outgoing-screen keying excluded, and four declared quantities
each shown not to separate the pairs.

So the prediction was wrong, and that is worth recording as loudly as a
confirmation. Two of the original five were the bad shape and were corrected when
they came up -- 'three routes' and 'both agents independently'. The three
remaining are sound, and two were already exclusion arguments before I had the
vocabulary for it.

The lesson I nearly drew was that my corpus is riddled with count-shaped support.
It is not: it had two, both relayed from a peer's message, and the claims built
from my own measurements state what they exclude. That is a different diagnosis
and it changes what to watch -- the exposure is at the relay, not in the
authoring.

Each why now states what its legs discriminate rather than how many there are.

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

authored/audio.json

@@ -140,7 +140,17 @@
     "⚠️ Second uncited MEASURED field in this one entry, after `loop_why`. Both",
     "described their evidence carefully in prose and pointed at nothing. A why that",
     "recounts a measurement reads as well-sourced precisely because it is detailed,",
-    "which is why neither looked wrong."
+    "which is why neither looked wrong.",
+    "",
+    "✅ AUDITED 2026-09-01 with the exclusion test: could either derivation have come",
+    "out differently given the other? YES, and they discriminate different errors --",
+    "(a) depends on a locally measured RATE and (b) on the CYCLE, so a wrong rate",
+    "breaks (a) and leaves (b) standing, and a wrong cycle does the reverse. Two legs",
+    "that fail independently, which is what 'two derivations' was claiming.",
+    "",
+    "⚠️ BOUND: they share one trace. A systematic error in the read_offset stream",
+    "moves both, and the ONE BOOT, ONE BANK caveat above is that limit stated. What",
+    "they exclude is arithmetic error, not trace error."
    ],
    "loop_start_kind": "measured",
    "loop_end_s": 61.87,

authored/flow.json

@@ -35,7 +35,7 @@
     "clock": "shared",
     "why": "MEASURED, 2026-08-29, docs/re/title-plate-delay-measured.md on branch auto/no-disc-and-menu-captures at 5b0a6e6 (NOT on main when this was written). The boot title shows build 4 ALONE and the `PRESS (A) BUTTON` plate -- build 2 -- arrives later. This is the ONE case in the port where two builds are drawn at once.",
     "no_constant_why": "THERE IS NO AUTHORED DELAY HERE, AND THERE WAS ONE FOR ONE ITERATION. The first version of this block carried `after_settle_seconds: 2.13`, taken from the RE agent's instruction. The port refuted that instruction with arithmetic off the disc -- build 2 has a group of its own, and starting it at settle put the plate 3.97 s late -- and the corrected answer needs no constant at all: BOTH BUILDS RUN ON ONE CLOCK, STARTED TOGETHER, and the plate arrives at its own declared t=238. `clock: \"shared\"` is that, spelled out rather than implied by the absence of a delay field. 📌 SOURCES, added 2026-09-01 in the uncited-why backfill: the plate's arrival is docs/re/title-plate-delay-measured.md and its pulse is docs/re/structures/plate-pulse-measured.md.",
-    "arithmetic_why": "Why one clock reproduces the measurement, checked against this export rather than taken on trust: build 4's visible build-in ends at t=118, where `pteff01`, `pteff02` and `ptlogoall_eff` finish together; `ptbtn00` reaches alpha 255 at t=238; the difference is 120 units = 2.000 s at 60 units/s. The oracle measured 2.138 s and 2.132 s. The gap is presentation rate: 120 units in 2.135 s is 56.2 units/s, i.e. the emulator presenting at 28.1 fps against a nominal 30, and the corpus had independently measured the idle title at 28.5 fps before these runs. 📌 SOURCE, added 2026-09-01: the pulse period and its phase behaviour are in docs/re/structures/plate-pulse-measured.md and docs/re/structures/plate-pulse-phase-lock.md, with the raw series in docs/re/data/plate-pulse-timeseries.txt.",
+    "arithmetic_why": "Why one clock reproduces the measurement, checked against this export rather than taken on trust: build 4's visible build-in ends at t=118, where `pteff01`, `pteff02` and `ptlogoall_eff` finish together; `ptbtn00` reaches alpha 255 at t=238; the difference is 120 units = 2.000 s at 60 units/s. The oracle measured 2.138 s and 2.132 s. The gap is presentation rate: 120 units in 2.135 s is 56.2 units/s, i.e. the emulator presenting at 28.1 fps against a nominal 30, and the corpus had independently measured the idle title at 28.5 fps before these runs. 📌 SOURCE, added 2026-09-01: the pulse period and its phase behaviour are in docs/re/structures/plate-pulse-measured.md and docs/re/structures/plate-pulse-phase-lock.md, with the raw series in docs/re/data/plate-pulse-timeseries.txt. ✅ AUDITED 2026-09-01: the corpus's 28.5 fps is a genuinely independent leg -- a different quantity (idle-title presentation rate), measured BEFORE these runs, so it could have come out disagreeing. It agrees to 1.4 %. That is corroboration rather than a restatement, which is the distinction the week's audits were about.",
     "the_premise_that_failed_why": "The port's own, and it is worth keeping because it will bite again: `rest.t` IS NOT WHEN A SCREEN SETTLES. It is the last hold keyframe before the exit. `ptlogo1` has rest.t=251 and stops MOVING at t=42, then creeps 5 px and 31 alpha steps over the next 209 units. Reading rest.t as the settle put build 4's arrival at 4.35 s instead of 1.97 s, and every reconciliation computed from it came out wrong by exactly that error. `ScreenView.settle_time()` still uses rest.t -- see docs/port/BLOCKED.md.",
     "scope_why": "Attached to the BOOT STEP, not to the `title` screen, and that is deliberate. What was measured is the boot title. Whether the title shows the plate when it is REACHED AGAIN -- by (B) from the main menu, or after the attract movie -- is not measured, and putting the overlay on the screen would quietly claim it is. 📌 SOURCE, added 2026-09-01: the plate belongs to the boot's overlay step rather than to the title screen because its arrival is measured against the boot clock -- docs/re/title-plate-delay-measured.md.",
     "no_pulse_why": "The port draws the plate arriving and then holding. It does not pulse it. The RE agent identifies the pulse as the plate's FOCUS RECORD `ptbtn00f` -- a glow ramping 0x00 to 0x50 and back, t=6..105 -- not as a loop of `ptbtn00`'s own group, which was the port's earlier reading and was wrong. Looping that record is a candidate the port has NOT taken: its group is 105 timed units plus an AUTHORED 24-unit exit ramp, and hitting the measured 2.24 s mean requires composing that authored constant with a loop assumption, which is tuning rather than measuring. Filed in BLOCKED.md. 📌 SOURCE, added 2026-09-01: docs/re/structures/plate-pulse-measured.md, and the phase-lock caveat that bounds what a gated capture can show is docs/re/structures/plate-pulse-phase-lock.md."

authored/timing.json

@@ -199,7 +199,9 @@
   "",
   "⚠️ An uncited measurement propagates as an uncited value. The receiving end",
   "cannot tell a summarised measurement from a recalled one, and both read as",
-  "prose."
+  "prose.",
+  "",
+  "✅ AUDITED 2026-09-01 and this one needed nothing: it was already an EXCLUSION argument rather than a count. It excludes a constant, excludes keying on the outgoing screen, and excludes every declared quantity in the export as a predictor -- four of them named, each shown not to separate the pairs. That is the form the week's other claims were found to be missing."
  ],
  "black_hold_kind": "measured"
 }

docs/port/DECISIONS.md

@@ -9,7 +9,7 @@ dies, which is what this file is for.
 
 <!-- INDEX: generated by tools/port/index-decisions -- do not hand-edit -->
 
-316 sections. Search this before re-deriving anything.
+317 sections. Search this before re-deriving anything.
 
 * [P0 — the exporter, 2026-08-28](#p0--the-exporter-2026-08-28)
 * [P1 — Godot draws the screen, 2026-08-28](#p1--godot-draws-the-screen-2026-08-28)
@@ -327,6 +327,7 @@ dies, which is what this file is for.
 * [The number in my decision document was stale the moment I committed it](#the-number-in-my-decision-document-was-stale-the-moment-i-committed-it)
 * [A command without a pass condition is half a check](#a-command-without-a-pass-condition-is-half-a-check)
 * [What every failure this week actually was](#what-every-failure-this-week-actually-was)
+* [The remaining multi-leg claims audited — and the pattern I predicted is not there](#the-remaining-multi-leg-claims-audited--and-the-pattern-i-predicted-is-not-there)
 
 <!-- /INDEX -->
 ## P0 — the exporter, 2026-08-28
@@ -15491,3 +15492,32 @@ test.
 doing, not whether it is correct.** Every entry in the list above was caught by
 somebody asking that about somebody else's sentence — and in four of the five, the
 somebody was the other agent.
+
+## The remaining multi-leg claims audited — and the pattern I predicted is not there
+
+I have listed *"four unaudited multi-leg claims"* as open for several iterations,
+and after the week's findings I said I **expected the same inversion in them**: a
+count standing in for an exclusion argument. Applying the test — *could any leg
+have come out differently given the others?*
+
+| claim | verdict |
+|---|---|
+| `loop_start_why` — *"two derivations, neither converts bits to seconds"* | ✅ **holds.** (a) depends on a measured **rate**, (b) on the **cycle** — a wrong rate breaks (a) and leaves (b), a wrong cycle does the reverse. They fail **independently**. ⚠️ Bound: one trace, so they exclude arithmetic error and not trace error — which the existing *"one boot, one bank"* caveat already says |
+| `arithmetic_why` — *"the corpus had independently measured 28.5 fps"* | ✅ **holds.** A different quantity, measured **before** these runs, so it could have disagreed. It agrees to **1.4 %** |
+| `black_hold_why` — *"I checked independently…"* | ✅ **holds, and needed nothing** — it was already an exclusion argument: a constant excluded, outgoing-screen keying excluded, and four declared quantities each shown not to separate the pairs |
+
+📌 **So the prediction was wrong, and that is worth recording as loudly as a
+confirmation would have been.** Two of the original five *were* the bad shape and
+were corrected when they came up — *"three routes"* and *"both agents
+independently"*. The three that remained are sound, and **two of them were already
+exclusion arguments before I had the vocabulary for it.**
+
+⚠️ **The lesson I nearly drew was that my corpus is riddled with count-shaped
+support.** It is not: it had **two**, both relayed from a peer's message, and the
+claims I built from my own measurements state what they exclude. **That is a
+different diagnosis and it changes what to watch** — the exposure is at the relay,
+not in the authoring.
+
+✅ Each `why` now states **what its legs discriminate**, rather than how many there
+are. That is the whole content of the week's finding applied to my own data: *the
+count was never the claim.*