Checkpoint ↔ code compatibility
A representation change breaks old checkpoints. This file records which code loads which arm.
| arms | conditioning | PER_SITE_DIM |
COND_DIM |
load with |
|---|---|---|---|---|
A_*, B_*, C_*, D_*, E_long*, F_scout, G_100* |
pre-WP-018 | 62 | 948 | commit 203c036 or earlier |
H_pq* and later |
WP-018 (+ per-shell SPECIFIED bit) | 68 | 1020 | commit 74dae8f or later |
Loading a pre-WP-018 checkpoint with current code raises:
size mismatch for site_proj.0.weight: copying a param with shape torch.Size([256, 62])
from checkpoint, the shape in current model is torch.Size([256, 68])
That is the correct, loud failure — not a corrupted download.
How this happened, and the rule it earns
WP-018 added a SPECIFIED bit per shell so a user could ask for fewer than six shells. That is a change to the input representation, and it silently invalidated 16 of 19 trained arms for inference. It surfaced only when a control experiment tried to feed a shallow query to a full-query model and torch raised a size mismatch.
RULE: a change to the conditioning or token representation is a BREAKING change. It must (a) be recorded in the checkpoint's own metadata, (b) be checked on load with a message that names the commit to use, and (c) appear in this table before the change is committed.
⚠ arm_meta.json records tokenizer_version and vocab_hash but not a conditioning version —
which is why nothing caught this at load time. Adding one is the fix; until then, this table is the
source of truth.