Two framing strings survived the sparsity-dense unification and contradicted the corrected data
After the 2026-04-18 sparsity-dense unification (see entry below) re-anchored every $/SCU and per-chip throughput number to dense BF16 (no 2:4 structured sparsity), two framing strings still pointed at the old convention. The /cost-index page header technical description told readers the index was computed against "BF16 TFLOP/s with 2:4 structured sparsity"; the FLOP Calculator’s sparsity explainer told policy readers that the Compute Cost Index "uses the alternative standard to match cloud provider billing conventions." A reader cross-checking the /cost-index header against the same page’s DataExport methodology string, the SourcesAndProcessing footer, or the dashboard’s footnote would have seen a direct internal contradiction.
Both pages now describe the actual convention: /cost-index says "dense BF16 TFLOP/s, no 2:4 structured sparsity"; the FLOP Calculator says the Cost Index "uses the same dense FP16 standard, so $/petaFLOP-day values compare directly to the throughput numbers shown here." The numbers themselves were always correct after the unification; only the prose around them was stale.
The sparsity-dense unification corrected the per-chip throughput constants in lib/methodology/versions.ts and the dashboard component, but two framing strings authored against the original convention were duplicated outside that code path. They survived because static prose looks invariant to type-checking and build verification, and because nothing in the audit step cross-referenced the convention string against the canonical constant.
A site-wide pass for "structured sparsity" / "sparsity-inclusive" / "FP8" mentions in framing copy was completed at the time of this fix. The recommended structural prevention — a build-time test that asserts every page-level convention string matches a canonical token derived from lib/methodology/versions.ts — is on the post-launch hardening list.