The owner's five class-B decisions — one sheet

Lane: assemble, not decide. Read-only pass over five parked findings; the numbers below are re-read from the tree on main at e638da7, and every claim names its file:line or its source document (§1.4). Nothing here was built, run or measured on this pass — a 100k-step train is live (PID 3129011) and .bulba/memory.md’s IO-pressure note forbids a --tests build beside it. Every performance number is quoted from a named log or document with its commit.

Vocabulary (docs/reviews/2026-09-30-kda-formula-audit.md:9-16, ADR-0020):

word	meaning here
tier (a)	checked against the authors’ own code, executed
tier (b)	checked line-by-line against a source that was read, not run
class A	the fix is a comment / transcription; no number moves
class B	the fix moves a number of a working model — owner’s call
SPECULATION	my inference, not measured here

Registered test tiers are in docs/protocols/ORACLE-TIERS.tsv (tests/kda_oracle.rs = tier a, :149; kda_oracle.txt = a, :151; fla_ops_kda_gate.py = a, :152).

---

0. Summary

#	decision	recommendation	blocks what if deferred
1	KDA read scale 1.0 vs head_k_dim**-0.5	fix to source — one literal at lib.rs:830, fused.rs:131,140; the mechanism is already green	every KDA number stays an 8×-wrong readout; docs/protocols/ORACLE-TIERS.tsv:149’s tier-(a) row cannot be quoted as “matches FLA” while it does not
2	DecayFn::Softplus arg order	fix to source — the running branch is untouched, and the falsify mutant that proves the fix is dead on arrival today (stale anchor)	A/B queue arm 5 is undefined: the arm would A/B a function that is not Kimi Linear’s
3	l2_normalize flat H*HD vs per-head	fix to source, but build the gate first — there is no red test for this, and the prior audit’s AGREE (b) verdict on it was wrong	the one KDA formula site with zero external coverage stays wrong and looks verified; decision 1’s “8× readout” number is not the whole readout error
4	TSCT fwd-factor latch re-aim	keep-and-document — re-aiming would measure a non-deployed arm and, on firing, switch the run into the arm with the drift	nothing blocks; the metric’s scope is already documented and the tsct= field already prints both arms
5	burn-sct delete-or-keep	delete — 2737 src lines, 1300 of them with zero tests, zero non-dev call sites, and the crate’s own README says DELETE	745 untested f64-SVD lines + ~300 dead stay in the largest crate of the library; docs/architecture/library-crate-fate.md:61 keeps carrying “DELETE (blocked)”

---

1. Read scale: 1.0 vs head_k_dim**-0.5

(a) What the code does today

// vendor/dormouse-fused/crates/burn-kda/src/lib.rs:830
chunk_wy_forward(q, k, v, g, b_k.clone(), b_v, state, 1.0, self.chunk_size)
//                        ^^^^ the scale argument, position 8 of 9

gdn2/src/forward.rs:649-659’s signature is (q, k, v, g, b, w_gate, state, scale, chunk_size), so position 8 is scale. The fused CUDA arm passes the same literal twice — vendor/dormouse-fused/crates/burn-kda/src/fused.rs:131 and :140, both state, 1.0, chunk_size,. kda_step (lib.rs:435) and forward_recurrent take no scale argument at all — there is no single literal that would fix them (kda-formula-audit-2026-09-30.md:499-505).

The crate below does the opposite. burn-gdn2 sets let scale = (hk as f64).powf(-0.5); at gdn2/src/module.rs:299. burn-kda is the only place in the library that overrides it to 1.0 (kda-formula-audit-2026-09-30.md:220-221).

(b) What the source says — tier (a)

source	what it says
fla/ops/kda/chunk.py:474-475	if scale is None: scale = K ** -0.5
fla/ops/kda/fused_recurrent.py:261-262	if scale is None: scale = k.shape[-1] ** -0.5
fla/layers/kda.py:262-278	calls chunk_kda(...) with no scale argument → the default is what the official layer runs
fla/ops/kda/naive.py:57	q = q.repeat_interleave(G, dim=2) * scale, folded before the loop — which is why the scan’s o = q·S comes out scaled

FLA @ 9f38d24980c46d46bd38614e743cdacd21906578, executed CPU 2026-09-30, torch 2.14.0+cpu. The two defaults are two independent transcriptions in one file (gate.py/chunk.py are separate files; the audit’s own wording is “two independent transcriptions inside one upstream file” for the decay pair — for the scale the two sites are chunk.py and fused_recurrent.py, i.e. two functions, one default, which is the stronger form).

At our shapes (configs/small.toml:6 head_dim = 64, confirmed in checkpoints/first_run_2000.config.toml:8): scale = 64**-0.5 = 0.125 = 1/8. The raw readout is 8× too large. (The brief’s “1/√8” is a naming slip — at head_dim = 64 the factor is 1/8, not 1/√8.)

Why the model has not noticed, stated exactly: the scale enters only the read o = q·S (lib.rs:11-12, Eq 1), never the state update, so it is one constant on the attention output. The next thing the crate does is output() (lib.rs:723-736), an RMSNorm with norm_eps = 1e-5 (lib.rs:191) over mean_dim(3), and an RMS norm is invariant to a constant rescale: c·o / √(mean((c·o)²)+ε) = o / √(mean(o²) + ε/c²). With mean(o²) = O(1) the residual is O(1e-5) relative. So this is invisible to every loss curve, seed comparison and in-crate test — and still real, because anything reading the raw attention output reads a tensor 8× too large (forward_recurrent’s pre-output tensor, oracle_breadth-style fixtures, a future decoder that skips the norm).

(c) The red tests

Two, red on purpose, not #[ignore]d (I read kda_oracle.rs; there is no #[ignore] anywhere in the file):

test	arm	what it asserts
read_scale_matches_fla_reference (kda_oracle.rs:618)	recurrent (kda_step)	ours (scale1_o) vs FLA’s default-scale row (scaleK_o)
chunked_wy_applies_no_read_scale (kda_oracle.rs:807)	chunked, both ChunkPath::Batched and ::Loop	same divergence on the deployed arm

And the green twin that makes the fix a one-literal change, not a port:

test	status	what it proves
chunked_wy_honours_the_read_scale_when_asked (kda_oracle.rs:776)	GREEN	asked for K**-0.5, chunk_wy_forward reproduces FLA’s own oK row ⇒ the mechanism is right, only the ARGUMENT is wrong

Plus a proof that the red is not “not what we happen to have written”: fla_read_scale_is_the_whole_difference (kda_oracle.rs:598) shows FLA’s two fixture rows are related by exactly the read scale.

Two stale cross-references in the evidence, found on this pass.

1. kda_oracle.rs:804-806 says “falsify.sh’s A6 is that demonstration”. It is not: falsify.sh’s A6 is the RoPE frequency mutant, and falsify.sh:164-186 carries a section titled “WHY THERE IS NO ‘TURN THE SCALE RED GREEN’ MUTANT” and explains why none exists.
2. docs/protocols/ORACLE-TIERS.tsv:149 cites src/lib.rs:646,653 and :268 for these sites. Those were the line numbers at the audit’s commit 3234ecc; on main they are lib.rs:830, fused.rs:131,140 and lib.rs:416.

(d) Options

option	cost	blast radius
fix-to-source	1.0 → head_k_dim**-0.5 at lib.rs:830 + fused.rs:131,140. kda_step/forward_recurrent need a new argument (they have none) — 3 sites, not 1, because the recurrent arms have no literal. Red tests go green; the green twin must stay green	22 of 24 config snapshots carry use_kda = true (measured: grep -l "use_kda = true" checkpoints/*.config.toml → 22; false → 2; none missing). Every KDA-bearing number moves by 8× on the raw readout, ~1e-5 relative after the RMSNorm — i.e. it invalidates nothing that survives rounding, but it is a class-B change by the rule and every checkpoint’s raw-readout consumer changes
keep-and-document	zero. The OPEN note is already written: lib.rs:38-53 and fused.rs:19-47	the archive keeps calling a crate “matches FLA” while one of FLA’s two defaults is overridden; burn-kda stays the only crate in the library that does this
delete the scale plumbing	n/a — not a real option; chunk_wy_forward needs the argument	—

(e) Recommendation

Fix to source — the mechanism is already green against FLA’s own row, the divergence is a documented false statement about the source, and leaving it makes the crate’s tier-(a) registry row unquotable; note it is 3 sites, not one literal, because the recurrent arms have no scale argument to change.

---

2. Softplus arg order (DecayFn::Softplus, A/B queue arm 5)

(a) What the code does today

// vendor/dormouse-fused/crates/burn-kda/src/lib.rs:392,416
let scaled = z_h.mul(a.exp());
...
DecayFn::Softplus => activation::softplus(scaled, 1.0).neg(),

i.e. g = −softplus(exp(A)·z) — exp(A) inside the softplus. The two comments that state the formula (lib.rs:21-27, lib.rs:394-414) were corrected on 2026-09-30 to match the code rather than the reverse (class A, landed).

The running branch is the other one. DecayFn::Sigmoid => activation::sigmoid(scaled).mul_scalar(self.g_min as f32) (lib.rs:421) is the default in both constructors (lib.rs:186, :207), and every checkpoint in the tree was trained with it.

(b) What the sources say — tier (a), two independent transcriptions

source	form
FLA naive_kda_gate (gate.py:27-52), executed	−A_log.exp() * F.softplus(g + dt_bias) — exp(A) outside
FLA triton twin (gate.py:167)	b_yg = -exp(b_A) * softplus(b_g) — outside, again
K3’s own §2.1.1	the running g_min · sigmoid(exp(A)·z) form, g_min = −5

Pinned at 9f38d249; gate.py:8 carries “This file is modified and supported by the Moonshot AI Team”, so the decay gate is Moonshot’s own file, not a third party’s reimplementation (kda-formula-audit-2026-09-30.md:96).

The arithmetic, at the crate’s own init (A = −3, b_alpha = +1):

	upstream	ours
argument to softplus	1.0	0.0498
g	−0.5544	−0.6692
alpha = e^g	0.5743	0.5120

They agree only at A = 0, and the ordering flips with the sign of A (at A = +1: upstream 2.718 vs ours 0.367). Different function, different curvature — not a reparameterisation, and not a monotone rescale of the decay.

(c) The red test

kda_linear_softplus_decay_matches_fla_reference (kda_oracle.rs:402) — RED ON PURPOSE, not #[ignore]d. Its green twin for the running branch is k3_bounded_decay_matches_fla_reference (kda_oracle.rs:334) — GREEN, character-for-character including g_min = −5.

No test in the crate can see the softplus placement, and the reason is structural: softplus_chunk_matches_decode and chunk64_matches_decode compare the chunk path against the per-token scan and both read the same KdaDecay::forward. A self-comparison cannot see a choice between two equally-valid answers (kda-formula-audit-2026-09-30.md:527-533).

The falsify mutant that proves the fix is dead on arrival today. tests/oracle/falsify.sh ships B1 — “softplus: exp(A) moved OUTSIDE (expect the softplus red to GO GREEN)” — precisely because “the two B mutants are the fixes the owner may choose” (falsify.sh:19-23). I counted its anchor against the current src/lib.rs:

anchor in falsify.sh	occurrences now
B1’s three-line lib.rs anchor	0
B1’s comment line alone (// Kimi Linear: g = -exp(A_h) * Softplus(z), alpha in (0, 1))	0
A1, A2, A3, A4, A5, B2, A6-rope, A7-rope, A8-rope	1 each (all still live)

patch() hard-fails on s.count(a) != 1 (falsify.sh:56-68), so B1 prints PATCH FAILED and demonstrates nothing. The anchor went stale when the class-A comment fix landed — the very fix that was correct. 10 of 11 mutants are live; the one covering decision 2 is not.

(d) Options

option	cost	blast radius
fix-to-source	the B1 mutant, re-anchored (3 lines, clones a and z_h). Red → green; the running Sigmoid branch is untouched	zero for any checkpoint: DecayFn::Softplus is not the default and no config selects it (measured: grep -n "DecayFn::Softplus" configs/*.toml → no hits; the enum reaches it only through KdaConfig.decay_fn, defaulted to Sigmoid at lib.rs:186, :207). Changes arm 5’s definition, which is the point
keep-and-document	zero; the OPEN note is written at lib.rs:21-27 and :394-414	arm 5 A/Bs a function that is not Kimi Linear’s, and the fixture row it is graded against is FLA’s
delete the branch	remove DecayFn::Softplus entirely	arm 5 becomes “replace DecayFn::Sigmoid with FLA’s softplus” — a different (and cheaper) arm. Loses the ability to hold the two side by side

(e) Recommendation

Fix to source — it is a 3-line change to a branch nothing selects, and leaving it makes A/B queue arm 5 measure the wrong function; re-anchor the B1 falsify mutant in the same commit, or the fix ships without its own proof.

---

3. l2_normalize axis: flat H*HD vs per-head

(a) What the code does today

// vendor/dormouse-fused/crates/burn-kda/src/lib.rs:671-672  — norm FIRST, on 3-D [B,T,H*HD]
let q_norm = l2_normalize(q_rot, 1e-6);
let k_norm = l2_normalize(k_rot, 1e-6);
...
// vendor/dormouse-fused/crates/burn-kda/src/lib.rs:686-687  — head split AFTER
let mut q_4d = to_4d(q_norm, h, hk);
let mut k_4d = to_4d(k_norm, h, hk);

l2_normalize is burn-gdn2/src/l2norm.rs:4-7: sum_dim(2) on a Tensor<3>, i.e. over the last axis of the flat [B, T, H*HD] — the whole concatenated head vector, all H*head_dim channels at once.

burn-gdn2 does it the other way, on the same tensor type family: gdn2/src/module.rs:533-534 splits to 4-D first (to_4d), then :541-542 calls l2_normalize_4d (l2norm.rs:13-15, sum_dim(3)). Its own comment says why: “The reference implementation normalizes q/k per head (each head’s own head_dim channels), so normalization must happen after the head split” (l2norm.rs:11-12).

(b) What the source says — tier (b)

source	what it says	tier
fla/layers/kda.py:255	q, k = (rearrange(x, "... (h d) -> ... h d", d=self.head_k_dim) ...) — the layer reshapes to head-major before calling chunk_kda	(b), read at 9f38d249 (docs/reviews/rope-2026-09-30.md:34)
fla/ops/kda/chunk.py:56-60	if use_qk_l2norm_in_kernel: q, q_rstd = l2norm_fwd(q); k, k_rstd = l2norm_fwd(k) — l2norm_fwd normalises the last axis of what it is handed, which is [B,T,H,K] ⇒ per head	(b), same read (rope-2026-09-30.md:51-53)
fla/ops/kda/naive.py:25,46	B, T, H, K = *q.shape — the ops API’s documented shape is 4-D head-major. Pinned in-tree at tests/oracle/upstream/fla_ops_kda_naive.py, registered tier a for shape (ORACLE-TIERS.tsv)	(b)/(a) for shape, not for the norm
gdn2/src/l2norm.rs:11-12	our own statement that the reference is per-head	(b)

Not tier (a). fla/ops/kda/chunk.py and fla/layers/kda.py are not pinned in-tree; both citations are reads recorded in the rope audit. The per-head claim rests on a chain, not on an executed row.

(c) The red test — there is none, and the prior audit’s verdict here was wrong

kda-formula-audit-2026-09-30.md:61 marks this site AGREE (b), justified:

“ours splits to heads at lib.rs:517-518 before normalising, so the axis is right”

Those lines are let mut q_4d = to_4d(q_norm, h, hk); — the split is AFTER the norm. I checked the audit’s own base commit 3234ecc (git show 3234ecc:…/burn-kda/src/lib.rs, lines 502-518): same order. The verdict was not wrong about the source; it was wrong about our code, by reading the split as the normalisation site. The rope lane already recorded the flat axis without flagging it as a divergence: docs/reviews/rope-2026-09-30.md:239-242 and tests/kda_rope.rs:424-425 — “l2_normalize over the flat H*HD axis (burn-gdn2/src/l2norm.rs:4-7)” — and asserts the commutation at both the flat norm and the per-head norm, so both are green.

Why no test can see it (structural, and this is the transferable part): the tier-(a) fixture’s q/k are raw standard normal [B,T,H,K] (tests/oracle/gen_kda_oracle.py:282-283, :303-305), and both the recurrent and chunked arms read them straight out of the fixture — kda_step_matches_fla_recurrent_at_unit_scale (kda_oracle.rs:489) and run_chunk (kda_oracle.rs:694) both call bthd_to_bhtd(t4(&blk.nums("q"), …)) and hand that to kda_step / chunk_wy_forward. Neither goes through KdaModule::project, so l2_normalize is never executed by any arm of the oracle. This is the same class as .bulba/memory.md’s “a gate covering the wrong half of the function”.

SPECULATION (arithmetic, not measured): this one is not absorbed by the output RMSNorm the way decision 1 is. With c_h = ‖q_h‖ / √(Σ_j‖q_j‖²), c_k(h) = ‖k_h‖ / √(Σ_j‖k_j‖²), Eq 1 gives erase ∝ c_k², write ∝ c_k, read ∝ c_q·c_k — different powers, so the delta-rule’s erase/write balance shifts per head and the function genuinely changes. Even at equal per-head norms (where every c_h = 1/√H, a global constant) the write is H^(−1/2) while the erase and read are H^(−1). I did not measure this; it follows from Eq 1, which is tier-(a) AGREE at naive.py:62-66.

(d) Options

option	cost	blast radius
gate first, then fix	add an arm that runs KdaModule::project’s q/k path and compares a per-head row against FLA’s l2norm_fwd — i.e. put l2_normalize inside the oracle’s coverage. Then the fix is one reorder (lib.rs:671-687: split before norm, as gdn2 does)	22 of 24 snapshots (use_kda = true) — the same class-B footprint as decision 1, and this one is not 1e-5-absorbed
fix-to-source now, no gate	~6 lines (reorder, or call l2_normalize_4d after to_4d)	as above, with no red test and no proof — a class-B numerics change landed on a code-reading argument alone, which is the thing §1.4 exists to prevent
keep-and-document	one comment at lib.rs:671	the one KDA site with zero external coverage keeps a wrong axis while ORACLE-TIERS.tsv and the audit present the site as AGREE (b) — a false claim in a registry, which is worse than an open item

(e) Recommendation

Fix to source, gate first — this is the only one of the five with no red test, and the audit verdict that called it AGREE (b) was itself wrong about our own code; building the gate is the whole job, and without it the fix has no evidence. SPECULATION: unlike decision 1 I do not expect this one to be absorbed by the output RMSNorm (different powers of c in erase vs write), so it is a larger blast radius than the read scale — measure before assuming otherwise.

---

4. TSCT fwd-factor latch: re-aim or document

(a) What the code does today

The latch — crates/dormouse-train/src/lib.rs:1408-1415:

if step % 500 == 0 && !ortho_fp32 {
    let ortho = model.max_ortho();
    if ortho > 1e-3 {
        println!("max_ortho {ortho:.2e} > 1e-3 - fallback fp32 factors");
        model.set_quant_all(burn_spectral::QuantFormat::Fp32);
        ortho_fp32 = true;
    }
}

One-way, and persisted in the checkpoint (lib.rs:594 CKPT_ORTHO_FP32, read back at :676, re-applied on resume at :710-714, announced at :1121).

What it reads — crates/dormouse-core/src/param.rs:213-225: burn_spectral::ortho_error(&u) / ku on the masters, per-entry F/k.

The other number — param.rs:231-243 fold_tsct_diag: burn_spectral::ortho_error_forward(&u, l.alpha), which is ortho_error_per_entry(ste_ternary_annealed(u, alpha)) at burn-spectral/src/lib.rs:431-433 — the function SpectralLinear::forward calls (lib.rs:665, :679).

(b) What is measured, and the fact that decides it

The live eval line (docs/reviews/tsct-diag-2026-10-01.md:109, a real 2-batch CPU --preset nano run):

tsct=6.90e-6/2.12e-8/6.59e-2/1.000e0/1.000e0/0@a=1.00
       bef     aft      fwd

The retraction works (aft 325× better than bef); the masters are held at 2.12e-8; and the forward factor reads 6.59e-2 — 66× over the latch’s own 1e-3 threshold. The latch cannot fire because it is a function of bef/aft alone. alpha is 1.0 everywhere and nothing in the repo sets it (burn-spectral/src/lib.rs:578 alpha: 1.0; grep set_alpha → only the crate’s own forward and its diag example) — so the whole history of the project has run at alpha = 1.

The fact that changes the recommendation. The latch reads max_ortho; the fwd number reads ste_ternary_annealed. But the deployed forward is:

// crates/dormouse-core/src/param.rs:120-123
} else if l.quant != burn_spectral::QuantFormat::Fp32 {
    l.forward_quant::<B>(x)      // quant_factor(master)  — NO ternary
} else {
    l.forward(x)                 // ste_ternary_annealed  — ternary applied
}

So the ternary arm is deployed only when quant == Fp32 — which is exactly what the latch’s remediation sets. The live 100k run prints quant format: Fp8 (8 bits) (logs/first_run_100000_1001_0202.log:1) and the spectral-stack-audit prices the same recipe at QuantFormat::Fp8 (spectral-stack-audit-2026-10-01.md:259-260). tsct-diag-2026-10-01.md:200-205 names this itself: “Under a non-Fp32 --quant (the sm_120 auto default is Fp8), fwd reports the TERNARY arm, not the deployed one … Named here rather than silently averaged in.”

Therefore re-aiming the latch at fwd would (i) gate on a function the run does not execute, and (ii) on firing, switch the run into the one quant format where that function IS executed. It would buy an fp32 forward (losing the factor-quant path at ~0.18 % arithmetic, spectral-stack-audit:244-245, on a launch-bound step) in exchange for a drift that is smaller, not larger, on the fp8 path.

And the latch is not broken at the job it was installed for: master drift is real and would cross it — the lm_head factor trains under AdamW (routing.rs:98) whose per-step ‖ΔU‖_F = 2.2e-2 is 28× the Muon+ factors’ 8e-4, i.e. 8 steps (systematic) to 63 (random walk) to the 1e-3 latch (spectral-stack-audit:54, F2). max_ortho measures exactly that, correctly. param.rs:205-212 already says so in the doc comment.

(c) The red test

ortho_forward_departures_from_the_masters_as_alpha_rises (burn-spectral/src/lib.rs:1539-1566) — GREEN (not a red test; it pins the metric’s three properties and its built-in cross-check):

• at alpha = 0 it equals the masters’ metric to 1e-12;
• at alpha = 1 it is > 100× the masters’;
• monotone in between;
• plus assert_eq!(masters, ortho_error_per_entry(&u)) — “Red by construction: the masters’ own metric CANNOT distinguish alpha = 0 from alpha = 1”.

Cross-checked end-to-end by tsct_field_format_is_golden_and_alpha_zero_is_the_cross_check (dormouse-train), and walked on the real eval path by tsct_diag_runs_on_a_real_two_batch_cpu_eval (tsct-diag-2026-10-01.md:186-187).

The eval-line field tsct=<bef>/<aft>/<fwd>/<smin>/<smax>/<off>@a=<alpha> already prints everything a decision needs (tsct-diag-2026-10-01.md:83-104).

(d) Options

option	cost	blast radius
keep-and-document	zero — the scope is already in param.rs:205-212 and the tsct= field already prints both arms	none. This is the recommendation’s core argument: the metric is not wrong, it is a master-drift metric, and nothing in the log ever claimed otherwise
re-aim the latch at fwd	new threshold + new one-way fallback + persistence changes; fwd would have to be read on the latch’s 500-step cadence (30+ device syncs, already noted at train/src/lib.rs:1402-1403)	would flip essentially every run to Fp32 — the brief’s “massive cost” is right in kind and unmeasured in magnitude (SPECULATION: the factor-quant path is ~0.18 % of the step’s arithmetic on a launch-bound step, so the honest cost is probably small — but it is not a number I can quote). Worse: it gates on a non-deployed arm and remediates into the drifting one
add the deployed arm’s metric (fold quant_format into the walk and report ortho_error of quant_factor(master) as a second field)	one more fold, one more field; named as the follow-up already at tsct-diag:204-205	none — additive reporting, no policy. This is the gap that actually matters: the fp8 factor’s own Gram error is unmeasured, and the fp8 arm is what actually trains

(e) Recommendation

Keep-and-document — fwd is a ternary-arm metric and the run’s deployed arm is quant_factor at Fp8, so re-aiming the latch would gate on a function the run does not execute and remediate into the one that has the drift; the real gap is that the deployed fp8 arm has no Gram metric at all, and that is an additive report, not a policy change.

---

5. burn-sct: delete or keep

(a) What the code does today — measured on this box, not quoted

fact	measurement
src/host_svd.rs	745 lines, 0 #[test] (grep -c "#\[test\]" → 0)
src/qr.rs	688 lines, 0 #[test\]
src/qr_cuda.rs	612 lines, 0 #[test]
src/lib.rs	692 lines, 13 #[test]
total	2737 src + 353 examples + 105 tests = 3195
untested lines in one crate	1300 (688 + 612), or 2045 counting host_svd.rs
#[test] total	13 (lib.rs) + 3 (tests/cuda_retract.rs) = 16
workspace member	yes — vendor/dormouse-fused/Cargo.toml:11 crates/burn-sct
incoming edges from a wired crate	exactly one, and it is a dev-dep: burn-spectral/Cargo.toml:33 [dev-dependencies], consumed by one example burn-spectral/examples/tsct_diag.rs:61-110
dependency from the trainer	none. grep -rn "burn-sct|burn_sct" crates/*/Cargo.toml Cargo.toml → no hits
src/ call sites from burn-spectral	zero (spectral-stack-audit-2026-10-01.md:88-90)

(b) What the source says

No external reference exists for the retraction’s accuracy — the paper prints the formula, not numbers (spectral-stack-audit:174-179). Honesty tier for the crate: (b) transcription of SCT 2604.00733 Eq 5, with the crate stating outright (:321-322) that there is no comparison against the authors’ code, and the comparison harness deleted (Cargo.toml:17-19, binary-tests removed 2026-09-27 “because it could only ever report PASS having asserted nothing”). The cmp_reference.rs “bit-exact” claim was UNVERIFIED (d) + false claim (docs/research/2026-09-27-oracle-audit.md:87, :127) — unrunnable by three independent routes.

The crate’s own README (burn-sct/README.md:3-9): “Not in the dormouse build, and duplicated in it … Recommendation: DELETE”.

(c) The “red test” — the correct instrument is the dead-code grep, and it is green

There is no red test, because there is nothing to fail. Two gates that cannot fail on a real error: retract_restores_ortho (lib.rs:529) and sign_correction (lib.rs:672) both assert |diag(UᵀU) − 1| < 0.1 on an 8- or 16-column factor — a retraction returning 90 % orthonormality passes both (spectral-stack-audit:158-164). The CUDA gate next door (gpu_retract_matches_cpu, 1e-4) is the one with teeth and it needs a GPU target. A gate that cannot fail is worse than no gate: it is a green line in a log.

bytes_f32 (lib.rs:254) is unsafe on two debug_asserts (16-byte alignment is an allocator’s habit, not a guarantee) — fine in a crate nobody calls, not fine as a pattern.

The one thing worth keeping is a kernel, unreachable for a named reason: qr_cuda::retract_cuda does the whole retraction in one launch vs the trainer’s ~54 per factor — but it is gated on is_cuda::<B>() against the bare CubeBackend (the trainer’s tensors are Autodiff { Cube(Cuda(0)) }), and SpectralLinear::retract has no backend type parameter at all, so it could not call it even with the gate open (spectral-stack-audit:121-131). The fix is not local — it is the parked fusion flip (ADR-0018/PLAN).

(d) Options

option	cost	blast radius
delete	drop vendor/dormouse-fused/Cargo.toml:11, burn-spectral/Cargo.toml:33, the sct_a/sct_b arms in examples/tsct_diag.rs:61-110, the burn-fused-benches path =, and the crate — ~10 lines per docs/architecture/library-crate-fate.md:159-172, which calls it “the single largest deletion available in the library”	zero numerics. No trainer path, no checkpoint, no config. Costs the 16 tests (green ones included, two of which cannot fail) and the one-launch kernel, which is unreachable anyway
keep as REFERENCE	fix param.rs:1 (says “TSCT linear via burn-sct”, the import at :6 is burn_spectral::SpectralLinear — a §1.7 defect) and burn-spectral/src/lib.rs:1 (calls itself burn-tsct)	the 2045 untested lines stay; the two name disagreements stay
keep as a kernel donor	the fused retraction on the trainer’s device — blocked by the fusion flip, so this is a plan item, not a task	—

docs/architecture/library-crate-fate.md:61 already carries the verdict: burn-sct | 2739 | 458 | d, b | DELETE (blocked).

(e) Recommendation

Delete — 2737 src lines with 1300+ carrying zero tests, zero non-dev call sites, and the crate’s own README recommending it; ADR-0002 (“a mechanism that does not beat its removal is deleted”) has nothing to weigh, because there is no A/B to run: nothing in the tree calls it.

---

6. Things this pass found that no findings file records

Reported because §1.4 makes an unrecorded finding a finding nobody acts on.

#	finding	evidence
N1	kda-formula-audit-2026-09-30.md:61’s AGREE (b) on the L2 axis is wrong about our code. It says “ours splits to heads at lib.rs:517-518 before normalising”; those lines are the split after. Verified at the audit’s own base 3234ecc — same order.	git show 3234ecc:…/burn-kda/src/lib.rs :502-518 vs main :671-687
N2	falsify.sh’s B1 mutant — the shipped demonstration for decision 2’s fix — no longer applies. Its anchor occurs 0 times in src/lib.rs; the other 10 anchors occur once each. patch() hard-fails on a non-unique anchor, so B1 prints PATCH FAILED and proves nothing.	counted against main:…/burn-kda/src/lib.rs; falsify.sh:56-68, :172-186
N3	kda_oracle.rs:804-806 cites “falsify.sh’s A6” as the scale-fix demonstration. A6 is the RoPE-frequency mutant, and falsify.sh:164-186 is a section explicitly titled “WHY THERE IS NO ‘TURN THE SCALE RED GREEN’ MUTANT”.	read both
N4	The two class-B gates spectral-audit-2026-10-01.md:827-830 reports as measured (“-- --ignored → 0 passed, 2 FAILED”) are not in burn-spectral/src/lib.rs on main — that file has zero #[ignore] (3050 lines). The names exist only in tests/oracle/falsify.sh:168 and two Python dry-runs (gate_dryrun.py:205, :230). They are on wt/spectral-audit (lib.rs:2795), which is not merged (git merge-base --is-ancestor 5aed8fc main → no; lib.rs differs by 688 insertions). falsify.sh’s section D would report NOT-DETECTED on main today.	measured on main; git grep on the branch
N5	docs/protocols/ORACLE-TIERS.tsv:149 cites src/lib.rs:268 / :646,653 for the two red sites; on main they are lib.rs:416 and lib.rs:830 + fused.rs:131,140. The class-A landing moved them and the registry did not follow.	measured
N6	The live 100k run is on the arm fwd= does not describe. param.rs:120-123 + quant format: Fp8 ⇒ the ternary projection is not in its forward; the tsct= field’s third number is the ternary arm. So the 6.59e-2 is real arithmetic and is not the run’s drift.	logs/first_run_100000_1001_0202.log:1, param.rs:120-123, tsct-diag:200-205

---

7. Open questions this sheet does not answer

1. Decision 3’s magnitude is unmeasured. SPECULATION above says the flat-axis error is not absorbed by the output RMSNorm (erase ∝ c², write ∝ c). That is arithmetic from Eq 1, not a run. The gate in (c) would price it, and until then decisions 1 and 3 must be costed as two separate class-B changes, not one “8× readout” story.
2. Decision 4’s cost is unmeasured in magnitude. “Would flip all runs to fp32” is right in kind; the fp32-vs-Fp8 factor-quant step cost is not a number I can quote (SPECULATION: ~0.18 % of arithmetic on a launch-bound step, so probably small — but “probably” is not a number).
3. The deployed fp8 arm’s Gram error is unmeasured, anywhere. That is the one forward-health fact a reader of any log in the archive does not have.
4. DecayFn::Softplus init arithmetic is settled but un-A/B’d — the A = −3, b = +1 pair is ours, not Moonshot’s or FLA’s (lib.rs:55-73), and kda-formula-audit:316-343 re-derives that the bias sign caps alpha at e^{g_min/2} = 0.0821, so neither knob alone reaches the reference family. Decisions 2 and this are the same arm; arm 5 cannot be specified until 2 lands.

---

Provenance of this sheet. Assembled 2026-10-01 from main @ e638da7. Every file:line was re-read on this pass; every number not re-read carries its document and commit. No cargo build, no test run, no GPU work — a 100k train is live (PID 3129011) and .bulba/memory.md records that a --tests build beside it IO-poisons the box. Nothing under vendor/ was modified.