Scope the phi rule to the records that declare it - #2792
Merged
Conversation
W701. The catalog gate applied the GoldenFloat generating rule
e = round((bits - 1) / phi^2), m = bits - 1 - e
to every record labelled `cluster=GoldenFloat`. That cluster holds four families
on two axes, and 41 of the gate's 43 findings were the rule being applied to two
of them.
THE RECORDS SAY SO THEMSELVES, in the field the gate parses:
bnf8 standard="... control for TNF8; width rule 1+E+M=N;
exponent sized for range not phi"
tnf8 standard="... e is 3 balanced-ternary TRITS not bits (4.75 bits
equivalent); width rule 1+Et+M=N"
gft8 standard="... GOLDEN RATIO axis: E_t = round((N-1)/phi^2)"
So the split is the data's, not mine. The file's own prose says it too, ten lines
above the flagged rows: "NOT the golden-ratio family ... Four formats, two axes."
And the numbers corroborate it twice over. Every bnf/tnf catalog e and m equals
the constants in the spec its `source=` names -- 17 of 17. Every bias is a closed
form of that same e: (3^e-1)/2 for tnf and gft, 2^(e-1)-1 for bnf, 22 of 22. A
mistyped exponent would strand its bias; none is stranded.
WHAT CHANGED. The three phi checks now run where a record declares
`rule=phi-ratio`, added to 30 records. A GoldenFloat-cluster record without one is
COUNTED and named in a single loud finding -- a skip nobody counts is the shape
this gate exists to refuse.
`tnf8` satisfies the phi rule and is deliberately NOT marked. At 8 bits the
range-sized and phi ladders coincide; encoding a coincidence at one width as a
design decision is how a catalog acquires a second wrong rule.
catalog gate 109 records, 43 findings, 42 unexpected
-> 109 records, 3 findings, 2 unexpected
GATE FAILURES 42 -> 2, and the ratchet demanded the re-bless:
"GATE FAILURES fell 42 -> 2 (-40) -- re-bless to pin"
The two that remain are real: `getter-parity` (109 records, 83 getters) and the
new `gf-rule-unstated` (17 records naming no rule).
FOUR CORRECTIONS TO MY OWN FIRST READING, from an adversarial audit run against
it. I had said: 42 findings (it is 43, of which 42 unexpected); zero findings on
gf*/gft* (gfternary does produce one, from a different check); two families (the
repository's taxonomy is four on two axes); and that bnf/tnf e-values "do not look
rule-derived at all" -- they are derived, by a documented rule that is not this
one. My logarithmic curve-fit was a red herring: the rule is "size the exponent
for the range, then 1+E+M=N".
AND ONE FINDING I WAS WRONG TO DISMISS. `tnf16` records phi_distance=0.086, which
is the value for m=9; the record and its spec say m=11, which gives 0.0417. It is
genuinely stale under the catalog's own convention -- flagged by the gate for the
wrong reason, but flagged. Not corrected here: it is the owner's numeric data and
this commit changes classification only. Filed separately.
cargo test --no-fail-fast 2437 passed, 0 failed
suite --ratchet RATCHET: CLEAN, exit 0
check_catalog_integrity.py exit 0
check_catalog_count.py exit 0
check_seal_coverage.py exit 0 (catalog re-sealed)
check_specs_generate.py exit 0
check_elab_ratchet.py exit 0
parse-conform 24/24
Refs #2762
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-29 08:12:59 UTC
Summary
Seal Status
|
…d changed
The withdrawn-number baseline is keyed by sha1 of the normalised line, BY DESIGN
-- its own header says "editing the line re-opens the gate, which is what we
want". Adding `rule=phi-ratio` to the gf16 CATALOG record edited that line, so
the gate re-opened and asked for the line to be re-confirmed.
Re-confirmed: the line still reads "323 MHz withdrawn, see RESEARCH_CLAIMS.md".
It is text ABOUT the retraction, not a live claim, exactly as before. One entry
re-keyed by hand rather than regenerating the file, so no other drift can ride
along.
I first computed the key from the raw line and got a hash the tool did not
recognise -- it normalises whitespace before hashing (`" ".join(line.split())`).
Reading how the key is MADE, not just what it looks like, is the difference
between a green gate and a second wrong hash.
check_withdrawn_live.py exit 0
Refs #2762
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
PR DashboardGenerated at: 2026-08-29 09:45:45 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-29 10:04:48 UTC
Summary
Seal Status
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #2762, #2787 · supersedes #2788 (rebased; master moved under it)
The catalog gate applied the GoldenFloat generating rule
to every record labelled
cluster=GoldenFloat. That cluster holds four families on two axes, and 41 of the gate's 43 findings were the rule being applied to two of them.The records say so themselves, in the field the gate parses
The split is the data's, not mine. The file's own prose says it ten lines above the flagged rows: "NOT the golden-ratio family … Four formats, two axes."
The numbers corroborate it twice: every
bnf/tnfcatalogeandmequals the constants in the spec itssource=names (17 of 17), and everybiasis a closed form of that samee—(3^e−1)/2for tnf and gft,2^(e−1)−1for bnf (22 of 22). A mistyped exponent would strand its bias; none is stranded.What changed
The three φ checks now run where a record declares
rule=phi-ratio, added to 30 records. A GoldenFloat-cluster record without one is counted and named in a single loud finding — a skip nobody counts is the shape this gate exists to refuse.tnf8satisfies the φ rule and is deliberately not marked: at 8 bits the range-sized and φ ladders coincide, and encoding a coincidence at one width as a design decision is how a catalog acquires a second wrong rule.The ratchet from #2784 demanded the re-bless on its first real improvement:
GATE FAILURES fell 42 -> 2 (-40).The two that remain are real:
getter-parity(109 records, 83 getters) and the newgf-rule-unstated(17 records naming no rule).Four corrections to my own first reading
An adversarial audit was run against this reading and corrected me: it is 43 findings not 42 (42 unexpected);
gfternarydoes produce a finding from a different check; the taxonomy is four families not two; and bnf/tnf e-values are rule-derived — by a documented rule that is not this one. My logarithmic curve-fit was a red herring.And one finding I was wrong to dismiss:
tnf16recordsphi_distance=0.086, the value for m=9, while the record and its spec say m=11 → 0.0417. Genuinely stale. Not corrected here — numeric data, filed as #2787.🤖 Generated with Claude Code