Accelerator FLOPS rows generated by repeatedly doubling a base figure instead of being read off the spec table produce a whole internally-plausible record that is wrong at every row

A record whose flops array is a clean geometric ladder - fp32 29.4, fp16 58.7 (2x), fp8 117.4 (4x), fp4 234.8 (8x) - which is exactly the shape NVIDIA's real tables have, so it passes a 'does this look sane' review, while every value is wrong. nvidia-rtx-5070 stored 7 rows, all 7 wrong. The true whitepaper row is fp32 30.9, fp16/bf16 61.7, fp8 123.5, fp4 493.9 - the ladder is real but the RATIOS are not 2/4/8: FP4 is 4x FP8 on this part, not 2x. So the record understated FP4 by 2.1x on top of a shared ~5% base error, and no amount of reading the stored values could reveal it.

The record's fp32 value was itself wrong (29.4, matching no published clock), and every other row was then generated by multiplying it by the tensor-to-vector ratio the vendor's footnotes imply, rather than transcribed. NVIDIA's consumer architecture whitepapers print each tensor row as an explicit 'dense/sparse' pair with the FP16-accumulate and FP32-accumulate variants listed SEPARATELY - e.g. RTX 5080 'Peak FP8 Tensor TFLOPS with FP16 Accumulate 450.2/900.4' versus 'with FP32 Accumulate 225.1/450.2'. These are different rows with different values, and FP4 exists only on the FP32-accumulate row. A generator that knows the rule 'tensor is 2x per halving of precision' invents numbers that NVIDIA never printed and that do not correspond to any hardware ratio. The failure is invisible to arithmetic self-checks because the internal ladder is perfectly consistent - consistency is not correctness.

Transcribe tensor rows, never derive them. A derivable value belongs in a *_basis field with its arithmetic shown, and only when the vendor actually publishes the derivation (it does for memory bandwidth from bus width x pin rate; it does not for tensor FLOPS). When a record's flops array forms an exact geometric ladder off a single base value, treat that as evidence of generation rather than of correctness and go back to the table. The specific check that caught this class: confirm each stored number APPEARS VERBATIM on the cited page, and cross-check against a sibling part in the same family that was transcribed rather than generated - nvidia-rtx-5070-ti reproduces exactly from its own table (8960 x 2 x 2452 MHz = 43.9; 28 Gbps x 256 / 8 = 896 GB/s), so a mismatch against it localises the fault immediately.

Second instance of the general 'generate from a ratio instead of transcribing' failure already recorded in this repo for vision-encoder cost records (3x FLOP error) and for kv_cache_bytes_per_token (16x, and an exact halving) - the pattern recurs across record types, so the rule generalises: derived-from-other-numbers is a schema *requirement* (a *_basis field) precisely because an undocumented derivation is indistinguishable from a transcription. NVIDIA's whitepaper footnote convention that makes the ratio guessing unnecessary: every tensor row carries footnote 2 'Effective TOPS / TFLOPS using the Sparsity Feature', while the 'non-Tensor' rows (FP32/FP16/BF16 non-tensor, INT32) and the RT TFLOPS row do not. Dense is always the FIRST number of the printed pair.