5: model_type example made concrete (loader code path, not release)

index.html

@@ -457,7 +457,7 @@ not the name, is the number (§5).</p>
 </tbody>
 </table></div>
 <p>Three comparisons carry claim 1 here. <strong>d4/K512 against the 2.6-bit
-community build:</strong> at 1.7 GiB larger (0.9 GiB without our vision
+community build:</strong> at 1.7 GiB larger (0.9 GiB without the vision
 tower), prose perplexity is better by
 0.6209 — 24 times the fit-to-fit floor — and code by 0.0544. No floor
 was measured at d4/K512 or d8; both here and in the d8 comparison below,
@@ -877,11 +877,12 @@ generated tokens through the exact runtime it ships with.</p>
 time, and a hash of the shard's head, stored outside the artifact —
 enough to identify a shard and to catch a silent rewrite, though not to
 certify every byte. Stored metadata is treated as a record of intent
-rather than of content: checkpoints inherit configuration fields from
-the bases they were converted from (every one in this lineage, for
-example, carries a <code>model_type</code> field from a different model release),
-so any stored property that carries a claim is verified against the
-bytes themselves — a tensor compared with its claimed base, a hash
+rather than of content. A checkpoint's <code>model_type</code> field, for
+example, names the loader code path rather than the model: Qwen 3.6
+and 3.8 share the 3.5 architecture, so their checkpoints all declare a
+<code>qwen3_5</code> variant, and every derived build inherits the stamp. A field
+like that cannot identify what a file contains, so any stored property
+that carries a claim is verified against the bytes themselves — a tensor compared with its claimed base, a hash
 recomputed, a flag traced to the code that reads it.</p>
 <p>None of this is novel; it is ordinary verification discipline, applied
 in a setting where the wrong numbers are the plausible ones.</p>