Sylpheed/docs/re/label-check-and-the-alpha-80-refutation.md

A check that reads the label, not the citation — and one refutation it turned up

Question: do the element labels in my F5/F6 findings still agree with the declared data?

What the human looks at: python3 tools/re-capture/check_labels.py — every line PASS. Then --selftest, which must FAIL.

What this does NOT cover: labels with no declared counterpart. Named below; that gap is real and unclosed.

✅ The check

Three of my errors were the label, not the measurement — 0x3003 read as a different role from 0x3002, and ptcopyright called "the plate" twice, the second time on a page written after I had corrected it. Every number was right. A correction living in one document did not reach the next one I wrote.

sylpheed-port built check-authored-vs-declared for values with a declared counterpart, and named the gap it leaves: a value that exists only in a capture and names an element rests entirely on my label. This is that case. Each identification was originally made by matching a declared quantity, so each is re-derivable:

[PASS] 1.1841 vs 1.2000 ( 1.3%)  pteff03a is the 720-unit leaf, not a second 600
[PASS] 1.3017 vs 1.3333 ( 2.4%)  pteff03a is the sy=800 strip
[PASS] 0.0993 vs 0.1000 ( 0.7%)  the pulsing slot has the declared 120-unit period
[PASS] 0.7500 vs 0.7333 ( 2.3%)  the -0.54 quad is ptcopyright (22-unit ramp)

Both captures, eight checks, all pass.

The control is the point. --selftest points the plate label at ptcopyright — the exact error I made — and it must fail:

[FAIL] 0.0180 vs 0.1000 (82.0%)  the pulsing slot has the declared 120-unit period
OK: mislabel detected (2 failures)

82–83 % against a 5 % tolerance, and the other three still pass, so the failure is localised rather than a global break.

🔴 RETRACTED — my refutation was wrong, and α80 is declared

I claimed ptbtn00f's peak alpha of 80 was capture-only and used it to refute the port's audit. Wrong. Verified on the disc myself with examples/leaf_keyframes.rs:

GP_TITLE entry 2 — ptbtn00f.rat (leaf 424 bytes), declared loop 120 units
  ptbtn00f.t32 — 8 keyframes
    t=0 a0 · t=6 a6 · t=29 a74 · t=35 a80 · t=50 a80 · t=58 a74 · t=97 a6 · t=105 a0

ptbtn00 carries two child records and I read one. ptbtn00.rat is the leaf — flat α255, which is what I found and described correctly. ptbtn00f.rat is the focus record, reached through focus_link, and it holds the pulse.

This is an absence claim from a search that did not cover the space. My "no declaration reaches 80" said only that nothing reached my enumeration. METHOD.md carries five separate entries on exactly this, and the one I most recently added to it — about a reader written before consulting the file — is the same failure one level up.

🟡 resolved with it: I doubted the corpus line "the plate pulses via ptbtn00f on a declared 120-unit loop". It is correct as written. ptbtn00f is in the record because it is the record.

✅ The gap I called unclosable is closed by the retraction

Because the amplitude is declared, it is checkable — so check_labels.py now verifies the shape, not just the period:

	mean |α| error vs the declared 8-key curve	best lag
f6	1.14 levels	0.90 frames
f6b	0.35 levels	1.00 frames

⚠️ The first version of this check assumed the onset frame was t=0 and f6b failed at 3.24 levels. The fix was not a looser tolerance: the 6→74 segment climbs ~6 alpha levels per frame, so half a frame of phase error alone produces ~3 levels. Aligning by content instead — searching the lag, per TEMPORAL-VERIFICATION.md — gives the table above. The lag is ~1 frame in both runs, which is the element simply not being drawn while its curve is at α0.

Reach

The check covers labels made by matching a declared quantity. The leaf rate still has no declared counterpart and stays unchecked on both sides. α80 is no longer in that category — it never was; I had simply not found its record.