A tok/s figure obtained by dividing a spec sheet's memory bandwidth by a guessed bytes-per-token is not a measurement, and it passes the load-condition rule because it inherits the right condition words

A record states a clean decode figure - 25 tok/s on an 8GB card, 120 tok/s on an RTX 5070, 22 tok/s on an M5 Max - and states its load conditions too: batch size 1, 512-token prompt, 128-token output, a named precision, a named backend. It looks like the model answer to 'does this record comply with the load-condition rule'. The conditions are all there. The number is still fabricated, because it was never measured: it was projected from the part's published memory bandwidth, and the source cited is the GPU architecture whitepaper or the vendor tech-specs page, which contains no tokens-per-second measurement of any kind. The tell is in the record's own prose, which says so plainly - 'the 614 GB/s bandwidth yields ~22 tokens/sec for decode', 'the 546 GB/s bandwidth yields ~18 tokens/sec'. Bandwidth divided by an assumed bytes-per-token is a roofline ESTIMATE. It ignores that a real decode step also pays attention over the whole KV cache, that the bytes-per-token constant is not a constant (weights are read once per step but KV grows with context), that prompt length changes the prefill/decode mix, and that the achievable fraction of peak bandwidth for a 4-bit decode kernel is itself the thing being estimated. The estimate can be off by 2x or more in either direction, and the resulting record carries a number precise enough to be quoted.

This is the load-condition rule's blind spot rather than a violation of it. The rule exists to stop a reader from treating an unconditioned number as comparable, and it is satisfied here by construction - the generic conditions were attached and they are true as statements about the intended configuration. The defect is upstream of conditioning: nothing in the record schema or the validator checks that a throughput value has a MEASUREMENT behind it, only that it has conditions and a source. A spec sheet is an acceptable source for a bandwidth or a capacity, and it is in the repo's source list, so citing one passes every mechanical check while supporting none of the numbers. Two aggravating details. First, bandwidth is a plausible input to a tok/s estimate, so the derivation looks like physics rather than invention - and the repo has a legitimate record family (flops/ridge-crossing, decode-gemm arithmetic-intensity) where exactly this arithmetic is correct, which makes the illegitimate use look like the legitimate one. The same arithmetic applied to a real measurement is a cross-check; applied to nothing it is a number from nowhere. Second, precise round values are self-certifying: 25.0, 120.0, 55.0 read as observed measurements to anyone skimming, and the record is then more trusted than the honest benchmark next to it that states it had to assume a condition.

Treat any tok/s figure as a measurement only if some source states it was observed, and require one of: a harness counter's output, a vendor page whose measured-throughput section it is (not a spec table), or a reproducible command line plus its raw log. Explicitly reject the pattern 'X GB/s yields ~N tokens/sec' - bandwidth is not a throughput measurement and there is no bytes-per-token constant that makes it one. When auditing a record, read the cited source for the number rather than the record's characterisation of it; in this repo's case all eleven offenders cited specification documents that contain no throughput figure, and the numbers appeared in no cited source at all. Secondary checks that catch the same family: (1) the HARD ROOFLINE, not a cross-card comparison - compute roof = memory bandwidth / weight bytes actually streamed per decode step, and a real batch-1 decode run CANNOT exceed it, because every token requires reading the weights at least once. On the eleven records here, five exceed their own roof: local-rtx-pro-6000-70b-q8-decode claims 55 tok/s against a 25.6 tok/s roof (215%), local-m5-max-70b-q4-decode 22 against 17.5 (125%), local-rtx-5080-32b-q4-decode 65 against 53.3 (122%), local-m4-max-70b-q4-decode 18 against 15.6 (115%), local-m5-ultra-70b-q4-decode 35 against 34.3 (102%). Correct the instrument before trusting it, though: for a MIXTURE-OF-EXPERTS model only the active experts are read per token, so the divisor is ACTIVE parameters, not total - applying the total-weight roof to Qwen3-30B-A3B or Qwen3.5-35B-A3B raises two known-good, reproducible records to 1328% and 336% of roof and looks like a finding when it is an artefact. With the MoE correction the same test passes 6 of 6 known-good third-party and vendor decode records (34-86% of roof), so it is a usable instrument. DO NOT use a 'slower card, higher tok/s' comparison across DIFFERENT models as evidence: the 672 GB/s RTX 5070 record runs an 8B model in ~5 GB (120 tok/s, 89% of its roof) while the 1792 GB/s RTX 5090 record runs a 32B model in ~18 GB (85 tok/s, 85% of its roof). Those two numbers are consistent with each other; only the workload differs. The genuine same-workload inversion in this family is local-rtx-5090-70b-q4-decode (45 tok/s against a 51.2 roof) against local-rtx-pro-6000-70b-q8-decode (55 tok/s against a 25.6 roof) - the same Llama 3.3 70B on two parts with identical 1792 GB/s bandwidth, where Q8_0 moves twice the bytes per token and so cannot run faster. That is arithmetic, not bandwidth-vs-tok/s confusion; (2) `reproducible: true` on a record whose source contains no run; (3) a note conceding the model does not fit the stated VRAM, which means the record describes a partially-offloaded configuration whose offload split is never quantified; (4) conditions that are identical across a whole record family are defaults being copied, not observations - when every record in a cluster states batch 1 / 512 / 128, those three values carry no information. Mark such records status: deprecated with the reason recorded, and do not delete them: a record that says its number came from a bandwidth estimate is useful evidence that the estimate was circulating, and the audit trail is what stops it being reintroduced. Keep the number in place rather than nulling it where the schema requires a number, so that anyone who has already seen the figure can find this explanation.

RE-AUDITED 2026-10-04 (independent pass over data/benchmarks/). The deprecation of all eleven local-* records is CONFIRMED on the primary basis stated in symptom - every one cites a spec sheet or whitepaper (7 citations of consumer-nvidia-rtx-blackwell-gpu-architecture-whitepaper, 5 of datasheet/spec-sheet records) and none contains a decode-throughput figure, verified by two independent methods: (a) corpus search for each recorded value in its own cited source record, zero occurrences in all 12 citations; (b) direct retrieval of the three primary documents (NVIDIA RTX Blackwell architecture whitepaper PDF, Apple MacBook Pro M4 Max tech specs, Apple Mac Studio tech specs), zero occurrences of "token", "throughput", "tok/s" or "inference" in any of them. The ROOFLINE paragraph above replaces an earlier internal-inconsistency test that compared two records running DIFFERENT models and was therefore not evidence of anything.