opus audit — Phase 3 local healing v2 verification #

scope: read-only verification of the v2 changes (scripts/heal_k256_q2_0.cpp, scripts/run_phase3_local_healing.py, scripts/patch_strata_metal.py, results/phase3_local_healing_validation.json, PLAN.md §2.7.A #31 and §7.1 item 6) against audits/opus_audit_phase3_local_v1.md. i re-ran the full 22-window / 2,686-token unseen KLD suite on the v2 model (the v2 report only ran 4 of the 22 windows), regenerated the v1 held-out 512-token MoE dump (bit-identical, ‖y_ref‖² = 36288.5374 both times) to compare v1 and v2 routed residuals, re-ran the ridge cross-validation probe on the new 1,022-token trace, and re-ran the 9-prompt speed suite on v2. no repo files edited; artifacts are in /tmp/p3audit/ (kld_results_v2.json, v2_eval_cal1024.tsv(.cv), v2_eval_heldout.tsv, speed_results_v2.json).

0. tl;dr #

• v2 is a real but small improvement over v1, and it's good vs unhealed. v2 vs unhealed on all 22 windows: −28.6% pooled KLD [−33.5, −23.2] at MoCE 0 (wins 20/22), −27.0% [−32.0, −22.1] at MoCE 0.85 (wins 21/22), top-1 +2.3 / +1.5 pt. v2 vs v1: −5.1% [−10.8, −0.1] at MoCE 0 (11/22 windows), −3.3% [−7.6, +0.4] at MoCE 0.85, and top-1 −0.3 / −0.5 pt (n.s.). on the 18 windows whose context shares no 16-gram with the new calibration trace, v2 vs v1 is −3.5% [−8.8, +1.5] → not distinguishable from v1.
• the routed-MoE local metrics improved cleanly and transfer: on the regenerated unseen 512-token dump, routed residual drops 24.13% (v1 shipped) → 23.37% (v2 shipped), with v2's real-trace α within 0.01 pt of the oracle and only 2/48 layers where α is worse than α=1 (was 22/48).
• japanese got worse vs v1 (ja KLD 0.172 → 0.180 at MoCE 0, top-1 85.0 → 83.7; 3 of 5 ja windows regress), while ops / chat-json improved. the canary 192-token set says v2 is worse than v1 (−23% vs −35%), PLAN.md reports v2's canary numbers without saying so.
• the "fixed tool-calling regression" is partly circular: the new calibration trace contains the same <tools> system block as the windows cj20_tool_5turn_t3 (117 shared 16-grams in its context), cj20_t3_answer_tool (117) and cj03_toolcall (43), and a different turn of the same persona conversation as persona3_t4 (85). the scored spans are clean (the self-test is right about that), but fixing cj20 by calibrating on cj20's boilerplate is in-distribution, not generalization. and the 4-window v2 benchmark in the results JSON includes exactly that window.
• code: the α, cache-fingerprint and I/O changes are correct. two real defects: (1) the yr_q2 fingerprint doesn't cover the gate/up experts, so a gain_gu sweep still silently reuses a stale cache; (2) "full-rank 640/640" is false for L0 (rank 430) and L2 (617). plus a doc/code mismatch on the W_down importance exponent. the stream.cpp guard is correct; the multi-chunk dump is untested (the 1,023-token dump is single-chunk) and holds whole files in RAM.
• stream.cpp / speed on v2: see §4.

1. code verification #

1.1 --quantize #

• W_gate/W_up importance: now w_d = sqrt(E[mixed_d²]) from the 1,022-token dump, used as the per-element weight on squared error in the LS/score. correct plumbing. note that the diag-Hessian-optimal weight on squared weight error is E[x_d²] itself (β=1); β=0.5 is a tempering choice, so call it that, not "AWQ". it's untested against β=1 or β=0. fine as a default.
• W_down importance: s_down[c] = (vg·vu)^(1/4), vg = Σ_d g_cd² E[x_d²], i.e. sqrt(σ_g σ_u). the header comment and PLAN say "SwiGLU RMS sqrt(E[h_c²])", but E[h²]^(1/2) ≈ σ_g σ_u, so the code uses β=0.25 on W_down vs β=0.5 on gate/up: an undocumented inconsistency. it also assumes diagonal, uncorrelated, zero-mean inputs and ignores the SiLU. the exact per-expert E[h_c²] is computable from the routed tokens in the same dump (≈20 tokens per expert on average, which is thin but unbiased; you could blend toward the analytic estimate). low priority, but fix the docs either way.
• the hc_ffn_norm fallback writes max(ms2·0.25, 1e-6) (a variance) into layer_s_in, while the real path writes an RMS. so the two code paths aren't on the same scale. harmless since the runner always passes cal_pfx, but the fallback should be sqrt(...) or deleted.
• for layers whose gate/up are already Q2_0 in the source, gate/up are still dequantized for the down importance only when td != Q2_0. that's correct.
• verified that stage 1 actually re-ran with the new binary: d_bak.bin 21:03 > heal binary 20:56 > .mixed 20:23.

1.2 --calibrate-and-heal #

• α (Part A): γ=0 → α = cos/ratio = ⟨y_ref,y_q⟩/‖y_q‖², computed over all tokens and all routed experts (via the routed yr_q2). my probe reproduces the shipped α to within 5.8e-5 of the in-sample oracle. the cos ≥ 0.1 clamp is inert. idempotent (rewrites from d_bak). ✓

• cache fingerprint: hashes d_bak (down scales) + layer-0 .mixed + t_cal. two holes:

  1. yr_q2 depends on the gate/up Q2 weights too, and those aren't hashed. a --quantize re-run that changes only gain_gu (or the gate/up importance β) leaves d_bak byte-identical (down importance is computed from the source gate/up, not the Q2 ones), so the stale cache is accepted. this is exactly the sweep scenario the fingerprint was meant to catch. fix: hash the healed .experts gate/up slices (or just its mtime+size), plus gain_gu.
  2. layer-0 mixed is a function of the embeddings/dense weights only, so a dump from a different expert quantization (e.g. re-dumping from Q2 instead of IQ3_S) hashes identical. hash a late layer too (e.g. L47 .mixed or .yr).

• ridge (Part B): math unchanged. my probe on the 1,022-token trace: rank(Z) = 640 for 46/48 layers, but L0 = 430 and L2 = 617, so "full-rank (640/640)" in PLAN.md is wrong for 2 layers (λ>0 keeps it well-posed anyway). effective dof at ρ=6 is 5–70 of 640. cross-validation (float ΔW):

  split	ρ=0.25	ρ=1	ρ=6 (shipped, η=.15)	ρ=24
  in-sample	−10.7%	−6.7%	−2.9%	−1.4%
  leave-one-block-out (4 contiguous)	−1.6%	−1.4%	−0.9%	−0.6%
  even/odd	−3.9%	−3.1%	−1.7%	−1.0%

  doubling T didn't change the picture: in-sample is still ~3× LOBO, and the realized gain after IQ4_NL requant is −1.10% in-sample (25 multipliers; v1 with 7 got −1.68% on its own trace) and −0.46% on the unseen dump (v1: −0.36%). still safe, still ~noise. the PLAN line "MoE MSE 19,061 → 18,665 → 18,461 (−3.15%)" is in-sample and mostly α (−2.08%), the ridge is the last −1.10%.

• writers file now holds only the 48 changed ffn_down_shexp tensors, transplant count 48 / 1175 untouched. ✓ error-checked I/O ✓. t_cal inferred from file size with divisibility check ✓ (but .ids/.wts/.yr sizes aren't cross-checked against it).

1.3 patch_strata_metal.py #

• stream.cpp guard if (moce_bonus_ > 0.0f) { wait + evict }: correct and matches the v1 recommendation. at MoCE 0 routing can't see smap_, so skipping is safe. source and binary are consistent (stream.cpp 20:27:45, CLI 20:28:12).
• multi-chunk dump_moe_layer: logic reads the previous whole file into a static std::map<ext, vector> at l=0 and rewrites [old rows | new rows] per layer. as far as i can trace it's correct for in-order layers, with these caveats: (a) it's never exercised, since the 1,023-token dump with PROMPT_CHUNK=1024 is a single chunk (T=1022); (b) per chunk it holds a full previous copy of .mixed, .yr and .hh in RAM (≈0.5+0.5+0.03 GB at T=1022, growing linearly) inside the inference process, and rewrites everything per chunk (O(chunks²) I/O); (c) first_chunk keys on last_T_ == 0 && s_pfx != pfx with static state, so a second dump in the same process with the same prefix appends instead of resetting (fine for the one-shot CLI, wrong for a server); (d) fseek with long is fine on macOS LP64 only. add a 2-chunk test (e.g. PROMPT_CHUNK=512 on the 1,024 file, compare against the single-chunk dump byte-for-byte) before relying on it.

1.4 run_phase3_local_healing.py #

• stage 1 is still skipped if .experts + d_bak exist, with no fingerprint, so changing gains or the cal trace requires manual deletion. same class of hazard as §1.2.
• verify_disjoint_calibration_prompts checks 16-grams of scored spans only. it passes, correctly. but it doesn't check contexts or doc identity, and the new trace shares context with 4 windows (§2.2). extend it to report context overlap and doc-level reuse, and fail on doc reuse.
• the results JSON's unseen_22window_2686tok_audit block is v1 numbers (copied from my audit file), not v2. that's labeled healed_v1_* in the keys, so it's honest, but PLAN.md mixes the v1 22-window and v2 4-window numbers in one bullet.

2. falsifier: full 22-window unseen KLD on the v2 model #

same 22 windows, same flags as v1 (§3.1 of the v1 audit). the IQ3_S reference was re-run and reproduced every window's PPL exactly (deterministic). v1/unhealed numbers are from the v1 audit runs, same binary family (the MoCE-0 path now skips the eviction wait, which can't change logits at MoCE 0).

2.1 pooled (95% CI = window bootstrap) #

comparison	KLD A → B	Δ KLD	windows B better	Δ top-1
unhealed → v2, MoCE 0	0.2029 → 0.145	-28.55% (-33.5, -23.2)	20/22	+2.27 (1.29, 3.4)
unhealed → v2, MoCE .85	0.2123 → 0.155	-26.98% (-32.0, -22.1)	21/22	+1.53 (0.41, 2.7)
v1 → v2, MoCE 0	0.1527 → 0.145	-5.08% (-10.8, -0.1)	11/22	-0.26 (-1.15, 0.51)
v1 → v2, MoCE .85	0.1602 → 0.155	-3.26% (-7.6, 0.4)	13/22	-0.52 (-1.39, 0.31)
v1 → v2, MoCE 0, 18 clean windows	0.1522 → 0.1469	-3.51% (-8.8, 1.5)	8/18	-0.37 (-1.35, 0.49)
v1 → v2, MoCE .85, 18 clean	0.1591 → 0.1568	-1.45% (-5.5, 2.0)	10/18	-0.51 (-1.56, 0.54)
isolated MoCE (m.85 vs own m0), v1 → v2	0.0389 → 0.0325	-16.53% (-28.3, -4.4)	16/22	+1.34

"clean" = the 18 windows whose full token file (context + scored) shares no 16-gram with cal_disjoint_1024tok.txt.

reading: v2 clearly beats unhealed (−28.6%, a bit more than v1's −24.7%) and the falsifier isn't triggered. v2 vs v1 is a small, marginal gain at MoCE 0 that loses significance once the 4 context-overlapping windows are dropped, and top-1 doesn't move. the clearest v2 win is isolated MoCE robustness (−16.5% vs v1).

2.2 per stratum, KLD / top-1 (token-pooled) #

model	ops	chat_json	ja	persona	pooled
unhealed, MoCE 0	0.1650 / 89.7	0.1554 / 89.5	0.2374 / 80.2	0.3576 / 72.1	0.2029 / 85.22
v1, MoCE 0	0.1199 / 90.9	0.1243 / 90.4	0.1723 / 85.0	0.2637 / 78.4	0.1527 / 87.75
v2, MoCE 0	0.1077 / 90.6	0.1130 / 90.8	0.1796 / 83.7	0.2527 / 77.9	0.1450 / 87.49
unhealed, MoCE .85	0.1589 / 91.4	0.1702 / 89.5	0.2513 / 79.6	0.3702 / 72.7	0.2123 / 85.55
v1, MoCE .85	0.1175 / 90.0	0.1341 / 90.2	0.1887 / 84.1	0.2683 / 80.7	0.1602 / 87.60
v2, MoCE .85	0.1070 / 90.6	0.1267 / 90.1	0.1929 / 82.2	0.2652 / 79.2	0.1550 / 87.08

ops and chat-json improve vs v1. ja regresses vs v1 (MoCE 0: 0.172 → 0.180, top-1 85.0 → 83.7; ja05, ja12, ja30 each 4–8% worse). persona is flat (−4% KLD, −0.5 pt top-1). so the new calibration mix traded some japanese for tool/ops. its only ja content is one doc (ja[2], ~100 tokens), versus a big block of tool calls.

2.3 the 4 context-overlap windows (†) #

the scored spans are clean, but the calibration trace contains the identical <tools> system block, and for persona3 a different turn of the same conversation:

window	shared 16-grams with cal (whole window)	v1 → v2 KLD (MoCE 0)
cj20_tool_5turn_t3	117 / 701	0.1783 → 0.1444 (−19%)
cj20_t3_answer_tool	117 / 742	0.0927 → 0.0430 (−54%)
cj03_toolcall	43 / 1064	0.0631 → 0.0621
persona3_t4	85 / 1974 (same doc, calibration_corpus conversation 3)	0.2856 → 0.2983 (+4%)

the cj20 "regression fix" is real but in-distribution. note that cj20 at MoCE 0 is now tied with unhealed (0.1444 vs 0.1440), not better. the results JSON's 4-window benchmark (ops12, cj20, ja22, persona0) was chosen after seeing v1's per-window losses and includes cj20, so its −29.7% headline is optimistic; the full-suite figure is −28.6%.

2.4 per window #

† = context shares 16-grams with the calibration trace.

window	unhealed m0	v1 m0	v2 m0	v2 vs v1	unhealed m.85	v1 m.85	v2 m.85	top1 m0 unh/v1/v2
ops14_csharp_bug	0.0797	0.0767	0.0775	+1.1%	0.0776	0.0834	0.0791	89.8/92.2/90.6
ops17_term_multiturn	0.0627	0.0331	0.0344	+3.9%	0.0595	0.0437	0.0374	95.3/95.3/95.3
ops19_term	0.0581	0.0513	0.0583	+13.7%	0.0603	0.0332	0.0456	93.0/91.4/93.0
ops12_java_turn1	0.3805	0.2778	0.2489	-10.4%	0.3384	0.2758	0.2567	79.7/82.8/82.0
cj03_toolcall †	0.0978	0.0631	0.0621	-1.6%	0.1349	0.0780	0.0731	96.1/98.4/99.2
cj20_tool_5turn_t3 †	0.1440	0.1783	0.1444	-19.0%	0.1534	0.1363	0.1417	91.4/89.8/91.4
cj15_php_review	0.0947	0.0703	0.0654	-6.9%	0.0959	0.0908	0.0838	85.9/89.1/87.5
cj19_italian	0.1779	0.1493	0.1497	+0.3%	0.1982	0.1839	0.1735	82.8/81.2/84.4
cj06_dostoevsky	0.4949	0.3406	0.3320	-2.5%	0.5289	0.3677	0.3618	78.9/82.0/79.7
cj07_json_extract_near	0.0420	0.0348	0.0349	+0.0%	0.0442	0.0322	0.0410	95.3/95.3/95.3
cj17_math	0.2147	0.1663	0.1645	-1.0%	0.2379	0.1839	0.1805	82.0/83.6/83.6
ja05	0.2284	0.1627	0.1691	+3.9%	0.2378	0.1666	0.1744	79.7/82.8/82.8
ja12_table	0.2305	0.1847	0.1982	+7.3%	0.2354	0.2060	0.2181	77.3/85.9/79.7
ja22_pedal	0.2965	0.1856	0.1845	-0.6%	0.3175	0.2114	0.2162	80.5/85.2/85.2
ja30_climate	0.2173	0.1750	0.1859	+6.3%	0.2397	0.1880	0.1833	82.0/85.2/86.7
persona0_t2	0.4100	0.2858	0.2878	+0.7%	0.4163	0.2945	0.3020	68.8/76.6/77.3
persona3_t4 †	0.3872	0.2856	0.2983	+4.4%	0.4340	0.3357	0.3125	73.4/76.6/73.4
cj07_answer_json	0.0006	0.0001	0.0001	-1.1%	0.0019	0.0001	0.0002	100.0/100.0/100.0
cj20_t3_answer_tool †	0.1030	0.0927	0.0430	-53.6%	0.1053	0.1090	0.0615	95.3/96.1/97.7
ja05_answer	0.1030	0.0625	0.0665	+6.5%	0.1058	0.0885	0.0753	86.4/90.9/86.4
persona0_t2_answer	0.2755	0.2197	0.1721	-21.7%	0.2603	0.1746	0.1811	74.2/82.0/82.8
ops19_answer_json	0.2441	0.1606	0.1194	-25.6%	0.2587	0.1515	0.1160	90.6/93.0/92.2

2.5 the 192-token canary #

v2 canary macro KLD 0.1563 vs v1 0.1320 (MoCE 0), i.e. v2 is 18% worse than v1 on the canary (−23.1% vs −35.1% vs unhealed). given §2.1, that's mostly the canary's 192-token noise, the same thing that made v1 look better than it was. but PLAN.md reports the v2 canary numbers as gains without the v1 comparison, which reads as if nothing got worse.

3. local MoE metrics on the regenerated unseen dump (512 tok, bit-identical to v1's) #

	α=1 (AWQ only)	shipped α	oracle α (on this data)	shipped α + ridge	layers α worse than 1
v1	24.31%	24.21%	23.81%	24.13%	22/48
v2	23.92%	23.48%	23.47%	23.37%	2/48

so all three v2 local changes transfer: the importance-weighted quantizer is −1.6% relative (α=1 column), the real-trace α now captures essentially all of the oracle gain (vs 20% for v1's Gaussian α), and the ridge adds −0.46%. caveat: this dump contains ~100 tokens of calibration_corpus conversation 1, which the new trace also samples (different region, 0 shared 16-grams, 4 shared 8-grams), plus the cj20 tool boilerplate.

4. speed / hit rate on v2 (9-prompt suite, MoCE .85 × 2 reps + MoCE 0) #

prompt	v1 hit (m.85)	v2 hit (m.85)	v2 misses/tok	v2 decode tok/s r0/r1	v2 det. r0==r1	v1 hit (m0)	v2 hit (m0)
ja_pedal_398	0.9276	0.9253	35.9	9.5 / 11.19	yes	0.8422	0.8471
json_extract_163	0.9560	0.9560	21.1	10.68 / 10.07	yes	0.8663	0.8699
tool_multiturn_588	0.9098	0.9088	43.8	13.17 / 11.71	yes	0.8290	0.8390
persona_458	0.9304	0.9126	41.9	11.14 / 11.04	yes	0.8453	0.8469
math_43	0.9443	0.9455	26.2	9.48 / 10.46	yes	0.8454	0.8469
ops_csharp_713	0.9249	0.9272	34.9	8.95 / 11.1	yes	0.8409	0.8422
coldshift_ja2rust	0.9394	0.9364	30.5	10.7 / 10.43	yes	0.8690	0.8661
prompt_43tok_wal	0.9313	0.9295	33.8	10.83 / 9.45	yes	0.8494	0.8551
prompt_1024tok_ops	0.9309	0.9248	36.1	11.71 / 9.14	yes	0.8448	0.8473

• mean combined hit at MoCE .85: v1 0.9327 → v2 0.9296 (−0.3 pt); MoCE 0: 0.8480 → 0.8512. persona_458 drops 1.8 pt (misses/tok 33.4 → 41.9) and ops1024 drops 0.6 pt (matching the results JSON's own 0.931 → 0.921). free-decode trajectories differ between models, so a single prompt is a single sample, but persona is the target workload: re-check it with more persona prompts before calling it noise.
• determinism: 9/9 bit-identical across reps at MoCE .85 on v2 ✓. MoCE 0 path (guard skips the wait) ran clean on all 9.
• PLAN.md §7.1 item 6 quotes the 9-prompt hit rates (93.27%, 90.98–95.60%) and 9/9 determinism as if they were v2. they are v1-model numbers. update them to v2: mean 92.96%, min 90.88% (tool), max 95.60% (json).

5. PLAN.md corrections #

1. "full-rank (640/640)" → 46/48 layers full rank; L0 rank 430, L2 rank 617.
2. "W_down by per-expert analytical SwiGLU RMS (σ_g σ_u)^(1/2)": that's E[h²]^(1/4), not the RMS. state the exponent honestly (β=0.25 vs 0.5 on gate/up).
3. the "4-stratum unseen benchmark −29.67%" headline → replace with the full 22-window v2 result: −28.6% [−33.5, −23.2] at MoCE 0, −27.0% at MoCE .85, +2.3 / +1.5 pt top-1, v2 vs v1 −5.1% [−10.8, −0.1] (n.s. on clean windows), ja regressed vs v1.
4. "eliminating the cj20 regression" → note the tool boilerplate in the calibration trace (in-distribution), and that cj20 is tied with unhealed, not better.
5. canary: add v1 → v2 (0.1320 → 0.1563, worse) next to the v2 numbers.
6. 9-prompt speed/determinism → v2 numbers (§4), including the persona hit-rate drop.
7. "0 16-gram overlap against all 22 unseen windows": true for scored spans only. add "4 windows share context (tools block / same persona conversation)".

6. recommendations #

1. ship v2 (it's at least as good as v1 and clearly better than unhealed), but quote −28.6% / +2.3 pt on 22 windows, not the 4-window number.
2. rebalance the calibration trace: more japanese (ja regressed), and swap persona conversation 3 for one that no eval window uses. then the tool/persona gains can be claimed as out-of-sample. the clean move is to freeze a doc-level split file (cal docs vs eval docs) and make the self-test enforce it.
3. fix the fingerprint (gate/up + late-layer hash) before any gain_gu / β sweep.
4. test the multi-chunk dump against a single-chunk dump byte-for-byte before using T > 1,022.
5. ridge: still ~0.5% out of sample. keep or drop; don't spend more on it.
6. next real lever: per-expert exact E[h_c²] for W_down and a β ∈ (0.5, 1) ablation for gate/up, both evaluated on the 22 windows plus a held-out ja/persona expansion. persona remains the worst stratum (KLD 0.25, top-1 78%).

---

v3 verification addendum #

re-checked PLAN.md (§2.7.A #31, §7.1 item 6), scripts/heal_k256_q2_0.cpp (identical to vendor/strata/metal/src/heal_k256_q2_0.cpp, binary rebuilt after the source), scripts/run_phase3_local_healing.py (--self-test PASS, re-run by me) and results/phase3_local_healing_validation.json. nothing re-measured; all numbers cross-checked against my v2 runs.

closed:

• PLAN.md: all 7 §5 corrections are present in both #31 and item 6:

  • rank 46/48 full, with L0 = 430 and L2 = 617;
  • the β = 0.25 vs 0.5 exponents;
  • the 22-window v2 numbers (−28.55% / −26.98%, +2.27 / +1.53 pt), plus v2 vs v1 −5.08% and the clean-18 −3.51% not significant;
  • the japanese regression;
  • cj20 being in-distribution and tied with unhealed;
  • the canary v1 → v2 got worse;
  • the v2 speed numbers (92.96%, persona 93.04 → 91.26%);
  • the 4 context-overlapping windows.

  no stale headline is left (no −29.67%, no "eliminating the cj20 regression", 93.27% only as the v1 reference).

• results JSON: the v2 22-window block and the v1/v2 9-prompt block match kld_results_v2.json / speed_results_v2.json exactly.

• yr_q2 fingerprint: now 4 × uint64: d_bak, L0 + L47 .mixed, gate/up of expert 0 at L0/L24/L47 from the healed experts, and t_cal. a global gain_gu / β change rewrites expert 0's gate/up, so it's now caught, and the L47 .mixed catches a teacher swap.

• cross-checks: .yr/.ids/.wts/.hh sizes are now checked against t_cal.

• fallback: the hc fallback now writes an RMS.

• self-test: it now asserts 0 scored-span overlap plus exactly 18/22 context-clean windows, and names the 4 overlapping ones.

still open (minor, none affects the shipped model):

1. run_phase3_local_healing.py skips Stage 1 if .quant.meta merely exists; it doesn't compare the stored (gain_gu, gain_d, cal_pfx, t_cal) against the values it's about to request. change the "0.50", "0.30" args and Stage 1 is still skipped. read the 3 uint64s and compare them.

2. .quant.meta hashes the cal_pfx path string, not the dump contents. the dump step likewise only checks that .mixed/.yr exist, so a re-made cal_disjoint_1024tok.txt under the same prefix wouldn't invalidate anything. hash the token file into the meta.

3. provenance: .quant.meta (22:43:19) and cal_teacher_yr_q2_1024.bin.meta (22:43:20) are newer than the data they vouch for: d_bak is 21:03 and the yr_q2 bin is 21:04. so they were written without re-running --quantize or recomputing yr_q2.

   • the d_bak + .mixed hashes would match regardless.
   • the gate/up sample is the one input nothing re-read: .experts was rewritten at 22:44 (α re-applied from d_bak, deterministic), but no --quantize ran.
   • stored quant.meta values: gain_gu 0.5, gain_d 0.3, t_cal 1022, which is consistent.

   fine for now. just don't treat these metas as having validated the cache. the next real run will recompute or confirm them.

4. the gate/up hash samples 1 expert × 3 layers. that's adequate for global knob changes, but it would miss a per-layer or per-expert-only edit. acceptable; document it.

verdict: v2 corrections verified. the remaining items are about cache/skip hygiene for future sweeps, not about the current K256-q2_0-healed artifact or its reported numbers.