The denominator moved under both of us, and it moved four days ago.
Your card finished flat on 2026-08-21 at 12:07Z. The published total is now
131,531,272 PHONE hits over 13,385 affected files, not 8,877,577. The
arithmetic closes exactly: 8,844,379 + 33,198 + 122,653,695 = 131,531,272, so
the old figure was part0 + part1 with flat still running.
Which means DynSP's one row is 2.84%, not 42.02%. I led with 42% and you
accepted 42%, and neither of us re-read the card. flat alone is 93.25% of the
new total.
But the mechanism is the part worth keeping, and I had that wrong too.
Those tokens are not bare digit runs. They are the weights themselves.
Same bytes as before: lfs.oid 43cc6276... equals my local sha256, file
unmoved since the 2026-08-18 upload.
The sentinels sit interleaved with survivors like 0.1089686 and -0.1168243.
The first sentinel block spans token index 24 to 3,737,146. Its numeric slots
come to 3,737,103 against a declared 100 x 37371 = 3,737,100. That block
is the whole first lookup table, and 95.85% of it is gone.
Inside that one block:
plain decimal survivors 152,427
leading integer digit '0' 152,427 of 152,427
digit counts 3..8 only, zero at 9 or 10
exponent-form survivors 2,717
with exactly 10 digits 2,422
with 9 digits 275
That is a control I did not have to construct. Same matrix, same weight
distribution, same 9-significant-digit Boost formatting. Plain 10-digit forms:
0 survive. Exponent 10-digit forms: 2,422 survive. The only difference
is the e-05 breaking the run.
So the matcher was a 10-digit rule, and it read the decimal point as a phone
separator. The eaten token is 0. plus nine digits.
Your section 4 is the fix. It is bolted to the wrong rule.
0 is not a legal NANP area code. The NXX range check you wrote into
namp_bare_run scores 0 of 152,427 on this file, applied to the leading
digit alone. Not "the overwhelming majority". Zero.
Put that check on rule 2 and all 3,730,704 hits in your top-1 file go away with
no file-class gate at all.
Rank 2 is not a weight archive, and it is the shape you already have a rule for
part0/mlops-with-podman.jsonl, 648,738 hits, 431,755 of them in one row.
sha256 == lfs.oid 2772bb7e....
It is a CSV. 100,000 data rows, every one exactly 28 columns wide.
redacted cell forms count column numeric density redacted
99.[PHONE] 185,280 Credit_Utilization_Ratio 100.00% 99,999 / 100,000
999.[PHONE] 180,588 Total_EMI_per_month 100.00% 86,138
9999.[PHONE] 47,652 Monthly_Balance 98.79% 98,743
[PHONE] 10,829 Amount_invested_monthly 91.22% 91,047
99999.[PHONE] 5,159 Monthly_Inhand_Salary 85.00% 52,934
Density is measured pre-scrub, counting a redacted cell as the number it used
to be. file_is_weight_archive cannot reach this file. column_is_numeric is
exactly the rule for it.
One line in your reply I would not sign
"file_is_structural was built for the PMR shape and it works, PMR matches the
card exactly, 261,575 = 261,575."
If the exemption had fired on PMR, PMR would read 0. A count matching the
card shows the scan is self-consistent, not that the exemption ran.
And the new rule brings a new false positive to the same file
5316420 occurs 48 times in the DyNet archive and survived the current
scrubber. Seven digits, leading 5, so it passes namp_bare_run's 7-digit leg.
It is a Dim array slot:
1 7 400 0 5316420 [PHONE] 32568 [PHONE]
Your new rule would eat 48 tokens the present one leaves alone, on the file it
was written to protect. The file-class gate saves it, which is the argument for
the gate. It is not an argument that weights fail the length-and-range check.
Your card's top-affected list still reads part0/DynSP.jsonl: PHONE 3249514
against 3,730,726 in the file.
So: which rule gets the range check first, the one you are adding or the one
that has already fired 131 million times?
