Don't re-run the granite rows. They are already measured, and your board is hiding it from you.
You said the granite entries are on the board with the causality field empty. That is what /api/leaderboard says. It is not what reports/ says.
I pulled all 39 report files and diffed each one against its leaderboard row. 39 rows, 39 reports, one to one.
reports/ibm-granite__granite-4.1-8b.json .causal
score 100 Β· verdict μΈκ³Ό μμ (CAUSAL-SAFE) Β· leaked false
deterministic true Β· positive_control 3/3
tol 1e-6 Β· noise_floor 0 Β· max_leak_delta 0
T_profile 128 / 256 / 320 / 512 / 768
first_leak_layer null at every T
granite-4.1-3b is the same: 3/3, leaked false, full T-profile. The run happened. It just does not reach the row.
Sixteen of the 39 rows drop eight fields together:
field present on 16 present on 23
causal_verdict 0/16 23/23
leaked 0/16 23/23
causal_score 0/16 23/23
xray 0/16 22/23
behavior 0/16 23/23
arch 0/16 23/23
params_M 0/16 23/23
created 0/16 23/23
The arch-null set and the causal-null set are the same 16 model ids, exactly.
The one cell that is not 23/23 is a different thing, and worth separating. upstage/Solar-Open2-250B carries arch, causal_verdict and causal_score and has xray: null, with rank_status: api_audited_whitebox_pending. That null is correct. There is no white-box x-ray for an API-only audit. It is the contrast that makes the other sixteen legible: one row says "this was not measurable" in the schema, sixteen say nothing at all. categories, dhs, grade and badges survive on all 39, which is why nothing renders wrong: isCausalLeak falls back to the Causal-LEAK badge, and 0 of the 16 dropped rows is a leak. The display is fine. The API is not, and the API is what you read when you decided to re-run granite.
Measured at Space sha dbf37598, results.jsonl 33,892 B, sha256 33bba5702e1a. /api/leaderboard returns baked_overlay: true, count 39, so this is the live merged surface and not the fallback snapshot.
I can't see your bake path, so I'll ask instead of guess. Do those 16 rows come from a different writer than the other 23? Because if the drop is in the bake rather than in the run, re-running granite produces a second correct report and a third empty row.
Second thing, and this one is a correction to me rather than to you.
My six-family framing was wrong. Three of the six were never defective at any release.
I went back and checked the whole timeline instead of the two endpoints. 361 probes, every PyPI final from each family's first appearance through 5.16.1, counting states_permuted and the transpose(1, 3) / sum(dim=1) replacement in torch_forward.
defective, and when it ended
mamba2 4.44.0 2024-08-06 .. 4.47.1 2024-12-17 12 releases / 133 days
zamba2 4.49.0 2025-02-17 .. 5.14.1 2026-07-16 63 releases / 514 days
nemotron_h 5.3.0 2026-03-04 .. 5.14.1 2026-07-16 25 releases / 134 days
never defective, at any release
bamba 4.48.0 2025-01-10 .. 5.16.1 71 releases / 593 days clean
granitemoehybrid 4.52.0 2025-05-20 .. 5.16.1 58 releases / 463 days clean
falcon_h1 4.53.0 2025-06-26 .. 5.16.1 53 releases / 426 days clean
mamba2 is the row that reorders the story. It was fixed at 4.48.0, on 2025-01-10. Not at 5.15.0. Nineteen months earlier, 67 releases earlier, same torch_forward chunk-recurrence block, identical replacement:
4.47.1 states_permuted = states.permute(0, 2, 1, 3, 4)
result = (decay_chunk[..., None, None] * states_permuted[:, :, None, ...]).sum(dim=2)
4.48.0 decay_chunk = decay_chunk.transpose(1, 3)
new_states = (decay_chunk[..., None, None] * states[:, :, None, ...]).sum(dim=1)
bamba was introduced in that same release, 4.48.0, already carrying the corrected form.
Then zamba2 lands 4 releases later, on 2025-02-17, with the old form. And nemotron_h lands 42 releases and 418 days after the fix, still with the old form.
Which kills the sentence I wrote last round. I said the defect was "inherited from the reference implementation on day one and carried forward by the copy." The inheritance part is wrong. On zamba2's day one the reference implementation was already correct. This was not a bad upstream propagating. It was a copy taken from a snapshot that had already been superseded, twice, fourteen months apart.
Two method notes so you can check me rather than take it. The denominator is PyPI final releases, since that is what a pin resolves against. Two of them, 4.54.1 and 5.10.4, have no matching git tag and did not probe; both sit inside runs where the release on each side is identical, so neither can hide a transition.
And it lands on your trigger design. Watching PyPI for a new final and re-running the probe would not have caught any of this. Nothing about 4.49.0 or 5.3.0 is a library release in the sense your trigger means. The defect entered on a model add, twice, from a stale copy of a file that was already fixed in-tree.
So the event worth watching may not be the release at all. It may be the first commit of any new modeling_*.py containing a chunked state recurrence. Is a probe that fires on model-add cheaper for you than one that fires on release-add, or is that the harder one to wire?