Skip to content

Oracle tiers

ORACLE-TIERS.tsv - what every reference comparison in burn-kda / burn-gdn2 is

ACTUALLY compared against. Read by tools/oracle_gate.py; the prose form is

docs/protocols/ORACLE.md. Tiers are ADR-0020’s: (a) AUTHORS (b) TRANSCRIPTION

(c) TRANSCRIPTION-OF-TRANSCRIPTION (d) NOTHING. (x) = not a correctness test.

“target” is the thing the expected value came from. If it names a function in

this fork, the comparison is arm-vs-arm and the tier is (d), whatever the

test’s own name says. That single column is the whole point of the file.

tab-separated. Waive a real violation by putting a reason in the LAST column;

an empty waiver is a FAIL. Waived rows print as DEBT on every run, so the debt

shows up in a diff instead of in somebody’s memory.

Generated by tools/gen_oracle_tiers.py - do not hand-edit; tab-separated files

lose rows.

2026-09-30: rows for the six “refs” taps were INSERTED BY HAND directly under

this header, against the instruction above, on purpose: tools/gen_oracle_tiers.py

and this file are desynced by another lane and regenerating has destroyed 22 rows

once. The generator is still the authority for every OTHER row. The reasoning,

and the per-tap “does a runnable reference exist” answers behind these rows, are

docs/archive/research/tier-a-references.md.

── burn-dspark: tier (a), the first time DeepSeek’s DSpark loss was ever RUN here

── the e2m1 grid and TIE RULE: torchao’s real MX-FP4 quantizer, run

── the e2m1 comparison, in the crate that OWNS the code (E2M1 lives in dormouse-core, not burn-bitnet)

── burn-mor and burn-attnres: upstream PINNED but NOT runnable; the absence is the finding

vendor/dormouse-fused/crates/burn-dspark/tests/dspark_loss_oracle.rs

Section titled “vendor/dormouse-fused/crates/burn-dspark/tests/dspark_loss_oracle.rs”
  • tier — a
  • target — RAN, not transcribed: deepseek-ai/DeepSpec@005e03b81cec38b7da6399833d609ee89a2587f2 deepspec/modeling/dspark/loss.py::compute_dspark_loss, executed on CPU 2026-09-30 (torch 2.14.0+cpu, gloo world_size=1) with the OFFICIAL alphas from config/dspark/dspark_qwen3_4b.py. VALUES AND GRADIENTS: the fixture’s grad_draft/grad_conf are the same pinned source back-propagated (compute_dspark_loss(...).backward()), so no formula of ours is in the gradient path either
  • catches — the CE, L1/TV and confidence-BCE terms AND d/d(draft_logits), d/d(confidence_pred) against DeepSeek’s own, on 8 cases. Found and fixed 3 defects: the confidence term’s numerical space (8.1 vs 20.3 on saturated_conf), the un-detached acceptance target (L2 1.227131 vs 0.073771 on saturated_conf, 16.6x), and the BCE spelling’s kink at x==0 (2x on 10 of 14 coords of aligned_identical)
  • cannot — the multi-anchor decay (upstream indexes it per block, we per flattened position; the generator holds A==1 rather than emit a reshape artifact); d/d(target_logits) - a frozen teacher output, which the trainer never back-propagates into; the denominator difference (den+1e-6 vs clamp_min(1.0)), real but unreachable and NOT covered by any case - no_fixture_case_reaches_the_denominator_difference is that fact executable; a FINITE-DIFFERENCE check of grad_draft, which cannot exist because the .detach() makes the returned scalar non-differentiable-consistent with its own graph (the FD converges to the LIVE target’s gradient, stably, h in [1e-3,0.2]); anything about DSpark QUALITY; the paper’s Eq. numbering

vendor/dormouse-fused/crates/burn-dspark/tests/oracle/gen_dspark_loss_oracle.py

Section titled “vendor/dormouse-fused/crates/burn-dspark/tests/oracle/gen_dspark_loss_oracle.py”
  • tier — a
  • target — the upstream it runs (DeepSpec@005e03b, torch 2.14.0+cpu pinned - unpinned the fixture diffs by the one meta.torch_version line every few weeks). It is the GENERATOR, and it refuses to write a fixture on which any of its four guards trips: its per-term attribution missing the official scalar by >1e-4 relative; grad_draft not BIT-IDENTICAL with and without a confidence head (the .detach() property); the recorded gradients disagreeing with its own differentiated transcription by >1e-3 relative (catches a mis-indexed recording); grad_conf missing a central difference of the official scalar. A golden file its own gate calls vacuous is the defect tier (a) exists to remove
  • catches — its own transcription of the per-term formulas is verified against the official scalar, so a slip that cancels in the total would survive; the differentiated transcription is a TIER (b) cross-check UNDER a tier (a) number, so it cannot prove the reference - only that the recording is not mis-shaped. A finite difference cannot check grad_draft at all (see the dspark_loss_oracle.rs row)
  • cannot — n/a

vendor/dormouse-fused/crates/burn-dspark/tests/oracle/upstream/deepspec_loss.py

Section titled “vendor/dormouse-fused/crates/burn-dspark/tests/oracle/upstream/deepspec_loss.py”
  • tier — a
  • target — VERBATIM deepseek-ai/DeepSpec@005e03b81cec38b7da6399833d609ee89a2587f2 deepspec/modeling/dspark/loss.py, sha256 2e91efcaff780eec0748ef3f6f0a31374f119f609c664cc79289fdd922335328, byte-identical to the copy already at crates/dormouse-core/tests/oracle/dspark_loss.py. Re-extractable with –dump
  • catches — the provenance of every fixture number
  • cannot — the arithmetic it dispatches to beyond what it spells out

vendor/dormouse-fused/crates/burn-dspark/tests/oracle/upstream/deepspec_common.py

Section titled “vendor/dormouse-fused/crates/burn-dspark/tests/oracle/upstream/deepspec_common.py”
  • tier — a
  • target — VERBATIM deepseek-ai/DeepSpec@005e03b deepspec/modeling/dspark/common.py, sha256 45273cf6c806cdb1ad24…, the DSparkForwardOutput dataclass that fixes the six input shapes
  • catches — the input SHAPE contract, including that block_keep_mask is Bool (& on f32 raises NotImplementedError) and eval_mask is Float
  • cannot — -

vendor/dormouse-fused/crates/burn-dspark/tests/fixtures/dspark_loss_oracle.txt

Section titled “vendor/dormouse-fused/crates/burn-dspark/tests/fixtures/dspark_loss_oracle.txt”
  • tier — a
  • target — GENERATED by tests/oracle/gen_dspark_loss_oracle.py by RUNNING the upstream above; 9 significant digits of the f32 it produced. Do not hand-edit - a hand-edited golden is exactly what tier (a) exists to replace
  • catches — -
  • cannot — -

vendor/dormouse-fused/crates/burn-bitnet/tests/oracle/gen_e2m1_oracle.py

Section titled “vendor/dormouse-fused/crates/burn-bitnet/tests/oracle/gen_e2m1_oracle.py”
  • tier — a
  • target — RAN: pytorch/ao@3972ed015091f659418dedf12edb980a8ca56b53 - fp_format_spec.float4_e2m1_interesting_values (the OCP MX FP4 grid, spec section 5.3.2 cited by URL in that file) AND mx_tensor::to_mx, torchao’s real block quantizer, on CPU 2026-09-30 (torch 2.14.0+cpu)
  • catches — that the e2m1 grid is 0/.5/1/1.5/2/3/4/6 with 0.75 ABSENT and 0.5 the single subnormal; and that the format breaks ties toward the EVEN CODE at all 7 interior ties
  • cannot — the NVFP4 block-scaled path (to_mx FLOOR vs RCEIL); any fp8/fp6 format; hardware quantizers
  • waiver — n/a

vendor/dormouse-fused/crates/burn-bitnet/tests/fixtures/e2m1_oracle.txt

Section titled “vendor/dormouse-fused/crates/burn-bitnet/tests/fixtures/e2m1_oracle.txt”
  • tier — a
  • target — GENERATED by the generator above from torchao’s own table and quantizer; 9 significant digits. Do not hand-edit
  • catches — the eight magnitudes, the per-tie reference answer, the round-half-to-even prediction and our ties-up answer
  • cannot — -
  • tier — a
  • target — RAN: pytorch/ao@3972ed01 torchao’s MX-FP4 quantizer, as generated above
  • catches — our E2M1 == torchao’s table, 0.75 absent, one subnormal, and ActFormat::Fp4.max_value() == 6.0 (the OTHER half of the 9b343d3 defect: scaling a block onto 1); RED on the TIE RULE - fp4_round is ties-up, the format is ties-to-even, disagreeing at 4 of 7 interior ties
  • cannot — the ternary/8-bit/4-bit-absmax paths in burn-bitnet, which have no e2m1 and no reference here

vendor/dormouse-fused/crates/burn-mor/tests/oracle/upstream/mor_expert_choice_router.py

Section titled “vendor/dormouse-fused/crates/burn-mor/tests/oracle/upstream/mor_expert_choice_router.py”
  • tier — a
  • target — the authors’ own MoR code, raymin0223/mixture_of_recursions@82c97f29cd140efa01f5cc4fe0de73a4c3b6ffd6 (KAIST AI / Mila / Google DeepMind, the paper’s own author list), VERBATIM. PINNED, NOT RUN: the module needs a transformers build with _static_cache_update in cache_utils, which transformers 5.17.0 does not have, so it cannot be imported here
  • catches — nothing by itself - it is the source a future runnable fixture must transcribe FROM, and the file that records three divergences found by READING it (our load_balancing_loss is mean((sigmoid(s)-n/T)^2) over active tokens; upstream’s token-choice balancer is sum(P_i * f_i), Switch-style, token_choice_router.py:300-306)
  • cannot — the claim of any numeric agreement - it was never executed

vendor/dormouse-fused/crates/burn-attnres/tests/oracle/upstream/attnres_README.md

Section titled “vendor/dormouse-fused/crates/burn-attnres/tests/oracle/upstream/attnres_README.md”
  • tier — a
  • target — MoonshotAI/Attention-Residuals@85e22310fe5ee860b4a023de312d791de8a5a5e6, VERBATIM README, PINNED. The official repository is SIX FILES: this README, the paper PDF, and 3 images - there is NO CODE upstream, so nothing can be run
  • catches — the authors’ own PyTorch-style pseudocode for block_attn_res, which is quotable external material and the ceiling for this tap (tier (b) transcribed from THEIR pseudocode, not from the paper’s typeset); it is where the 1/sqrt(d) divergence was found
  • cannot — any numeric agreement

vendor/dormouse-fused/crates/burn-kda/tests/cuda_gate.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/cuda_gate.rs”
  • tier — d
  • target — in-crate KdaModule::forward_recurrent (per-token scan) + burn_gdn2::seam_counts
  • catches — chunked-WY algebra vs the exact scan; SEAM (which arm ran); nonzero parameter grad on AdBal
  • cannot — anything in project/output (shared by all three arms); the fused CUDA kernel (this fixture DECLINES it on purpose); paper semantics

vendor/dormouse-fused/crates/burn-kda/tests/ops_grad_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/ops_grad_cuda.rs”
  • tier — d
  • target — central finite differences of the ops forward (independent METHOD, not an arm)
  • catches — the chunk op’s adjoint on the trainer’s backend; a real q_proj.weight derivative; 8 coordinates/tensor
  • cannot — the fused CUDA kernel; PAPER semantics

vendor/dormouse-fused/crates/burn-kda/tests/fused_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/fused_cuda.rs”
  • tier — d
  • target — in-crate forward_recurrent + burn_gdn2::chunk_wy_forward
  • catches — the fused chunk CUDA kernel forward; the chunked algebra; both DecayFn forms
  • cannot — project/output; the fused gradient (asserts only nonzero); ragged T; the fused DECODE kernel (KDA dispatches to the tensor scan, not a kernel)

vendor/dormouse-fused/crates/burn-kda/tests/bench_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/bench_cuda.rs”
  • tier — x
  • target — none
  • catches — (nothing asserted)
  • cannot — -

vendor/dormouse-fused/crates/burn-kda/examples/bitforbit.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/examples/bitforbit.rs”
  • tier — d
  • target — in-crate forward_recurrent + chunk_wy_forward
  • catches — dumps tensors for an off-tree FLA cross-check; asserts nothing itself
  • cannot — any claim of bit-exactness - both sides are our own arms
  • waiver — R5 (the FILENAME says bit-for-bit) is waived, not fixed: renaming collides with a [[example]] name = entry in burn-kda/Cargo.toml, two dated research logs that quote cargo run --example bitforbit, and a generated graphify report. The docstring is corrected in this lane and now says so in its first line; the RENAME is a follow-up for whoever owns burn-kda.

vendor/dormouse-fused/crates/burn-kda/examples/bitforbit_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/examples/bitforbit_cuda.rs”
  • tier — d
  • target — in-crate forward_recurrent, same tensors as the CPU dump
  • catches — fused chunk kernel vs the CPU-dumped scan inputs; asserts nothing itself
  • cannot — any claim of bit-for-bit - both sides are our own arms
  • waiver — R5 (the FILENAME) waived for the same reason as bitforbit.rs, plus Cargo.toml:35 declares name = "bitforbit_cuda" explicitly, so the rename is a Cargo edit and not a git mv. Docstring corrected here.

vendor/dormouse-fused/crates/burn-kda/examples/kda_bench.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/examples/kda_bench.rs”
  • tier — x
  • target — none
  • catches — (nothing asserted)
  • cannot — -

vendor/dormouse-fused/crates/burn-kda/examples/kda_step_probe.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/examples/kda_step_probe.rs”
  • tier — x
  • target — none
  • catches — (nothing asserted)
  • cannot — -

vendor/dormouse-fused/crates/burn-gdn2/tests/alloc_probe.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/alloc_probe.rs”
  • tier — x
  • target — none
  • catches — all 4 tests #[ignore]d; allocator counters only
  • cannot — any correctness claim

vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_chunk.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_chunk.rs”
  • tier — d
  • target — in-crate chunk_wy_forward (ops) + central finite differences
  • catches — CHUNK (custom-node forward vs per-op); GRAD (analytic adjoint vs FD, but 1 argmax coordinate per input at 5% rel)
  • cannot — the fused CUDA kernel (CPU build); project/output; every coordinate the 7 probes do not land on

vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_cuda_gate.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_cuda_gate.rs”
  • tier — d
  • target — in-crate chunk_wy_forward + seam counters
  • catches — backend gate decision; the fused kernel reaching a Balanced graph; fused-vs-ops numerics; a wrong d_k/d_g
  • cannot — project/output; any non-CUDA backend

vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_nested_balanced.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_nested_balanced.rs”
  • tier — d
  • target — in-crate, NoCheckpointing vs BalancedCheckpointing
  • catches — the checkpoint-strategy transposition; that the op declines a nested graph
  • cannot — the numerics; the fused kernel

vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff.rs”
  • tier — d
  • target — in-crate fused_recurrent_forward (scan) vs chunk_wy_forward; decode vs prefill
  • catches — CHUNK; STATE carry; prefill->decode handoff; 5 config-refusal tests
  • cannot — project/output (used as FIXED input); the fused CUDA kernel

vendor/dormouse-fused/crates/burn-gdn2/tests/b5_seam_probe.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/b5_seam_probe.rs”
  • tier — d
  • target — hand-written host rank-5 references in the same file
  • catches — LAYOUT: swap_dims(3,4)/matmul/cumsum/slice/permute on rank 5
  • cannot — anything about the recurrence

vendor/dormouse-fused/crates/burn-gdn2/tests/bench_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/bench_cuda.rs”
  • tier — d
  • target — in-crate fused_recurrent_forward; fused_step directly at :204
  • catches — the fused DECODE CUDA kernel, per token, state and output. NOTE: the file is named bench but :204 is a real assert!; only bench_cuda at :87 is #[ignore]d
  • cannot — project/output; the fused CHUNK kernel

vendor/dormouse-fused/crates/burn-gdn2/tests/bench_fused_bwd.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/bench_fused_bwd.rs”
  • tier — x
  • target — none
  • catches — times the fused adjoint and discards the result
  • cannot — -

vendor/dormouse-fused/crates/burn-gdn2/tests/bench_tracks.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/bench_tracks.rs”
  • tier — x
  • target — none
  • catches — (nothing asserted)
  • cannot — -

vendor/dormouse-fused/crates/burn-gdn2/tests/bench_train_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/bench_train_cuda.rs”
  • tier — x
  • target — none
  • catches — (nothing asserted)
  • cannot — -

vendor/dormouse-fused/crates/burn-gdn2/tests/fused_adjoint_vs_ops.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/fused_adjoint_vs_ops.rs”
  • tier — d
  • target — in-crate chunk_wy_forward per-op autograd, on bare tensors
  • catches — the fused CUDA ADJOINT, on two shapes chosen to localise a wrong term
  • cannot — the fused forward; the state OUTPUT (a leaf on both paths, so d_s there is the INPUT state’s gradient)

vendor/dormouse-fused/crates/burn-gdn2/tests/fused_chunk_verify.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/fused_chunk_verify.rs”
  • tier — d
  • target — in-crate chunk_wy_forward
  • catches — the fused CUDA chunk forward; zero-key-row gradient finiteness
  • cannot — its own fused_op_grads_match_tensor_path_cuda, which compared the TENSOR adjoint to the tensor path (see that file’s header)

vendor/dormouse-fused/crates/burn-gdn2/tests/fused_launch_count.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/fused_launch_count.rs”
  • tier — d
  • target — two hand-written CUDA kernels in the SAME file (spec-flashkda.md §1: fwd_kernel1.cuh + fwd_kernel2.cuh)
  • catches — the launch COUNT of the module path vs the scratch path, i.e. that a call that grew an extra kernel is visible; nothing numeric
  • cannot — any correctness claim - this is a counter, and a count cannot see a wrong answer
  • waiver — registered (d) and not (b): the two kernels it compares against are in this file, so arm-vs-arm is the whole comparison. Requires cuda,autodiff and does not run in the default cell.

vendor/dormouse-fused/crates/burn-gdn2/tests/fused_permuted_view.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/fused_permuted_view.rs”
  • tier — d
  • target — in-crate, strided vs contiguous views
  • catches — the seam on NON-CONTIGUOUS input (the stack overflow); contiguity left alone
  • cannot — the numerics of the recurrence

vendor/dormouse-fused/crates/burn-gdn2/tests/lowp_bf16_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/lowp_bf16_cuda.rs”
  • tier — b
  • target — IEEE-754 round-to-nearest-even, via the third-party half crate - the one reference in the tree that is neither our code nor our transcription
  • catches — bf16 STORAGE as u16 bit patterns + f32 accumulation; the f32-only dtype gate
  • cannot — the recurrence; anything else
  • waiver — ‘bit-exact’ is CORRECT here and the one legitimate use of the word outside tier (a): the expected value is half::bf16::from_f32, a third-party implementation of IEEE-754, not another arm and not our transcription. Registered (b) not (a) because the half crate is not the mechanism’s authors’ code, so ADR-0020’s AUTHORS label would be a different kind of false claim.

vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_autodiff.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_autodiff.rs”
  • tier — d
  • target — central finite differences of the plain path + cross-arm
  • catches — RAGGED tail (T not divisible by chunk) in the custom node’s backward; both arms
  • cannot — project/output; the fused kernel

vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_bench_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_bench_cuda.rs”
  • tier — x
  • target — none
  • catches — (nothing asserted)
  • cannot — -

vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_diff.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_diff.rs”
  • tier — d
  • target — in-crate chunk_wy_forward_loop (the untouched production arm)
  • catches — CHUNK: the finite-Neumann rewrite, 9 cases incl. a hostile one and a ragged tail; TILE routing past 32
  • cannot — project/output; the fused kernel; gradients

vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_grad_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_grad_cuda.rs”
  • tier — d
  • target — central finite differences of the same forward on Autodiff<CudaBare, BalancedCheckpointing>
  • catches — GRAD for BOTH arms on the trainer’s backend; 8 coordinates/tensor at a 5% rel bar
  • cannot — project/output; the fused kernel

vendor/dormouse-fused/crates/burn-gdn2/tests/official_forward.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/official_forward.rs”
  • tier — b
  • target — arXiv:2605.22791 Eq 9/10/11/12 and §3.5, re-derived in f64 per token in THIS file - a transcription, and a no-fixture one, so it is runnable rather than committed
  • catches — PAPER-SEMANTICS across 10 configs x 2 entry points; its own short conv, its own head-major layout, its own reduction order (it shares no code with the chunked path); TOL = 1e-5, measured 5.04e-09
  • cannot — the authors’ own Triton kernel (never run); the 4-D/strided stages the example dumps
  • waiver — the f64 layer (ref_f64.rs) is the fixture-based sibling of this one; the two disagree in TIER, not in verdict - this file has no committed bytes, so a reader can run it, and ref_f64.rs is the one CI can diff. docs/papers/gdn-kda.md carries the arXiv id because the file cites the equations through that report rather than the paper directly.

vendor/dormouse-fused/crates/burn-gdn2/tests/ref_f64.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/ref_f64.rs”
  • tier — b
  • target — tests/ref_f64.bin, emitted by tools/gen_reference_f64.py, itself an f64 transcription of arXiv:2605.22791 Eq 9-12 with the three non-paper lines (the 1/sqrt(K) scale, the short conv’s ZERO left pad, the L2-norm eps inside the sqrt) each citing the file it came from
  • catches — PAPER-SEMANTICS; project; short_conv_1d; output; the STATE carry; both dispatch arms; 18 cases T=1..70
  • cannot — the authors’ own Triton kernel (never run - ORACLE.md §8 candidate (2), not attempted). A shared MISREADING of the paper survives a transcription, which is why this is (b) and not (a)
  • waiver — RED until 2026-09-29 and the cause was THIS LAYER, not the kernel: the generator reshaped g head-major while q/k/b/v used the token-major idiom, and the two coincide at T=1 only, so case 0 passed and case 1 read 9.227e-02. The whole episode is in the file’s STATUS block. It is a second instance of the ff7cd57 generator-layout defect, in a file written after that fix.

vendor/dormouse-fused/crates/burn-gdn2/tests/common/ref_f64.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/common/ref_f64.rs”
  • tier — b
  • target — the same ref_f64.bin + tools/gen_reference_f64.py as ref_f64.rs; it is the shared reader, not a test of its own (a leading-underscore-free file in tests/ would be)
  • catches — the FIXTURE FORMAT: magic, header, and the ‘no trailing bytes’ assertion. Asserts nothing about any number
  • cannot — everything numeric - it contains no comparison at all, only the loader and the module builder the two callers share
  • waiver — registered as a file because R1 scans tests/ mechanically and an include!d helper is not a test target. Waiving it would leave the loader undeclared, and the loader is where a silent format change would land.

vendor/dormouse-fused/crates/burn-gdn2/examples/ref_f64_stages.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/examples/ref_f64_stages.rs”
  • tier — b
  • target — the same f64 transcription as ref_f64.rs, but per-STAGE: tools/gen_reference_f64.py --diff-stages reads this example’s dump and compares each stage separately
  • catches — the DIAGNOSTIC, not a verdict: it names the FIRST stage of project that disagrees with the f64 transcription, which is how the 2026-09-29 g-reshape defect was localised in minutes rather than by bisecting the layer
  • cannot — the 4-D permuted stages, which it does NOT compare: this backend’s into_data() on a strided view does not read in a stable order, so a 4-D row would be a false positive (see the example’s header)
  • waiver — it is an example, not a test: cargo test never runs it, so it can never be the thing that keeps a regression out. It is the instrument, and the gate that uses it is the one in the tier (b) sibling.

vendor/dormouse-fused/crates/burn-gdn2/src/lib.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/src/lib.rs”
  • tier — c
  • target — tests/ref_data.bin (our transcription, same as bit_exact.rs)
  • catches — a feature list
  • cannot — its binary-tests bullet said ‘bit-exact reference tests’, which is a tier-(a) claim about a tier-(c) fixture. ADR-0020 listed the same defect in the README; the doc comment was missed and is fixed in this lane

vendor/dormouse-fused/crates/burn-kda/src/lib.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/src/lib.rs”
  • tier — d
  • target — n/a - no fidelity claim in the file
  • catches — (documents the Kimi Linear / K3 equations, which is provenance, not a comparison)
  • cannot — any numeric claim: no test in this crate compares against either paper

vendor/dormouse-fused/crates/burn-gdn2/src/lib.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/src/lib.rs”
  • tier — b
  • target — the f64 fixture layer (same as oracle_breadth.rs)
  • catches — a feature list
  • cannot — its binary-tests bullet used to say “bit-exact reference tests” about a tier-(c) f32 fixture; rewritten 2026-09-29 to name the f64 transcription, the 1e-3 relative bar, and that it is neither bit-for-bit nor tier (a)
  • waiver — the bullet names the tier-(a) vocabulary ONLY to disclaim it (ADR-0020 R2 fires on the phrase, not on the claim): ‘Not bit-for-bit, and not tier (a)’

vendor/dormouse-fused/crates/burn-gdn2/tests/oracle_breadth.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/oracle_breadth.rs”
  • tier — b
  • target — tests/ref_f64_broad.bin, emitted by tools/gen_reference_f64.py: an f64 transcription of arXiv:2605.22791 3.1 Eq. 8-12 (tools/gen_reference_f64.py), with the three details not in the paper each cited to the authors’ own source: lit_gpt/gdn2_ops/chunk_gdn2.py for the K**-0.5 scale on the whole readout, fla/modules/conv/triton/kernels.py for the ZERO pad, fla/modules/l2norm.py for eps inside the sqrt
  • catches — PAPER-SEMANTICS; project (layout, L2 norm, decay parameterisation, GVA repeat); short_conv_1d; output (gate, o_norm, o_proj); the STATE carry. 1000 cases at T in 1..=38 - the T sweep of the fixture it replaced, so the breadth is preserved and only the oracle changed
  • cannot — the fused CUDA kernel, and the chunked arm (that is oracle_chunk.rs). RED on a pre-existing state-carry defect: measured worst 8.9402e-01 relative, 976/1000 cases over the 1e-3 bar; every stage of project clean to <= 5.2e-07 including all seven per-head 4-D tensors, and token 0 correct at every length
  • waiver — the header names the tier-(a) vocabulary ONLY to disclaim it (ADR-0020 R2 fires on the phrase, not on the claim). See the STATUS block for the measured tier-(b) wording

vendor/dormouse-fused/crates/burn-gdn2/tests/oracle_chunk.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/oracle_chunk.rs”
  • tier — b
  • target — tests/ref_f64_broad.bin (the same f64 transcription as oracle_breadth.rs)
  • catches — PAPER-SEMANTICS at chunk sizes 4/8/16/32/64 over the same 1000 cases, plus chunk-vs-fused under REAL per-channel decay at T=130
  • cannot — the fused CUDA kernel. Its own arithmetic: the chunked arm re-orders a DIFFERENT factorisation (the chunked WY solve), not the same loop, so it needed its own arm - and measured, the pre-existing defect swamps it (identical 8.9402e-01 worst at all five sizes)
  • waiver — the header names the tier-(a) vocabulary ONLY to disclaim it (ADR-0020 R2 fires on the phrase, not on the claim). See the STATUS block for the measured tier-(b) wording

vendor/dormouse-fused/crates/burn-gdn2/tests/ref_f64.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/ref_f64.rs”
  • tier — b
  • target — tests/ref_f64.bin (18 cases) and tests/ref_f64_faults.bin (the seven wrong formulas): an f64 transcription of arXiv:2605.22791 3.1 Eq. 8-12 (tools/gen_reference_f64.py), with the three details not in the paper each cited to the authors’ own source: lit_gpt/gdn2_ops/chunk_gdn2.py for the K**-0.5 scale on the whole readout, fla/modules/conv/triton/kernels.py for the ZERO pad, fla/modules/l2norm.py for eps inside the sqrt
  • catches — PAPER-SEMANTICS on both dispatch arms at T=1..70, plus the NEGATIVE CONTROL: the_bar_bites_a_wrong_formula asserts on every run that our output is at least 1e-1 relative from each of the seven, so the bar cannot rot into a self-consistency check
  • cannot — the fused CUDA kernel. RED on the same pre-existing state-carry defect (9.227e-02 at T=2, measured on base dbfa4ca before this retarget); its STATUS block records the localisation and the one measurement that could not be reproduced
  • waiver — the header names the tier-(a) vocabulary ONLY to disclaim it (ADR-0020 R2 fires on the phrase, not on the claim). See the STATUS block for the measured tier-(b) wording

vendor/dormouse-fused/crates/burn-gdn2/tests/common/ref_f64.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/common/ref_f64.rs”
  • tier — b
  • target — the loader for both f64 fixtures, and build() for the module under test
  • catches — nothing on its own: it is include!d by ref_f64.rs, oracle_breadth.rs, oracle_chunk.rs and the ref_f64_stages example. It is not a test target
  • cannot — everything, since it is where a fixture-layout or builder error would enter all four

vendor/dormouse-fused/crates/burn-gdn2/examples/ref_f64_stages.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/examples/ref_f64_stages.rs”
  • tier — b
  • target — reads the f64 stages out of project and the generator diffs them one at a time (--diff-stages)
  • catches — a STAGE against an outside reference rather than two arms against each other, which is the only way to see inside project. It is what localised this crate live defect to the state carry, and what confirmed the 0a6998a conv-pad fix (3.0e+00 -> 1.7e-07)
  • cannot — the recurrence and output - it stops at the end of project by construction. A TOOL, not a gate: it has no assertions

vendor/dormouse-fused/crates/burn-gdn2/tests/official_forward.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/official_forward.rs”
  • tier — b
  • target — an f64 per-token transcription of Eq 9/10/11/12 written from the papers, with NO fixture
  • catches — the forward as the equations state it, 10 shapes x 2 entry points, on NdArray. It predates the f64 fixture layer and is the tier-1 answer to the same question
  • cannot — the CUDA kernels (it runs on NdArray, so it covers the tensor paths only)

vendor/dormouse-fused/crates/burn-rmsnorm/tests/rmsnorm_oracle.rs

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/rmsnorm_oracle.rs”
  • tier — a
  • target — RAN, not transcribed: torch.nn.functional.rms_norm (torch==2.14.0+cpu, pytorch/pytorch v2.14.0, ATen torch::rms_norm) and fla.modules.layernorm.rms_norm_ref (flash-linear-attention==0.5.2, fla-org/flash-linear-attention, sha256(fla/modules/layernorm.py)=e78b729b..c6d6f), both EXECUTED 2026-09-29 on CPU and emitted to tests/fixtures/rmsnorm_oracle.txt at 9 significant digits. Both are byte-pinned as transcripts under tests/oracle/upstream/, so the gate needs no network. The two upstreams agree with each other to 0.0 relative on all 12 cases (identical f32), so the expected column is not a compromise between two opinions. Regeneration command: tests/oracle/gen_rmsnorm_oracle.py
  • catches — the eps INSIDE-vs-OUTSIDE-vs-DROPPED question (the decisive cases sit at rms 5e-5..2e-3, where the gaps are O(0.1..1); the worst is 44538x the tolerance); the LayerNorm-style centring misreading (1962x); the reduction axis (122173x on a square cube); eps as a parameter of the call, checked by running the kernel at eps=1e-5 and eps=0 on ONE tensor; the per-feature gain broadcast (non-constant gains on 11 of 12 cases)
  • cannot — the fused CUDA kernel, which this file’s arithmetic never touches - it is covered separately, and correctly so, by tests/rmsnorm_kernel_cuda.rs (it DOES run on a bare device, and the trainer never has one); WHETHER either upstream faithfully transcribes arXiv:1910.07467, whose AUTHORS SHIP NO CODE, so tier (a) here means ‘the two public reference implementations of the mechanism’, not ‘the authors of the paper’. A shared misreading of Zhang & Sennrich survives this test. The bf16 and f64 paths

vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/gen_rmsnorm_oracle.py

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/gen_rmsnorm_oracle.py”
  • tier — a
  • target — the same two upstreams it runs (torch 2.14.0+cpu, flash-linear-attention 0.5.2). It is the GENERATOR, and it REFUSES to write a fixture on which the upstreams disagree by more than 1e-6, or on which any of the crate’s own guards would be unsatisfiable
  • catches — is the fixture’s provenance: the sha256 of the fla file it read, the torch tag, and the 9-significant-digit encoding that round-trips f32
  • cannot — anything about the Rust tree - it writes no Rust

vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/mutate_kernel.sh

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/mutate_kernel.sh”
  • tier — x
  • target — n/a - it runs the crate’s own tests against deliberately wrong kernels
  • catches — that the oracle CAN FAIL: five mutants of RMSNorm::forward’s tensor path (eps outside the sqrt / dropped / hardcoded, gain collapsed to its mean, reduction over dim 1), each of which turns at least one test red. It asserts nothing about the numerics itself
  • cannot — -

vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/upstream/torch_rms_norm.py

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/upstream/torch_rms_norm.py”
  • tier — a
  • target — verbatim inspect.getsource() of the two PyTorch entry points that were executed, from torch 2.14.0+cpu (pytorch/pytorch v2.14.0). TRANSCRIPT of upstream source, re-extractable with gen_rmsnorm_oracle.py --dump
  • catches — which upstream code was run, so the version in the fixture header is not an unbacked claim
  • cannot — the arithmetic: it dispatches to COMPILED C++ (aten/src/ATen/native/layer_norm.cpp::rms_norm), which is not quotable here and is not pinned by this file

vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/upstream/fla_rms_norm_ref.py

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/upstream/fla_rms_norm_ref.py”
  • tier — a
  • target — verbatim inspect.getsource() of fla.modules.layernorm.rms_norm_ref from flash-linear-attention 0.5.2 (fla-org/flash-linear-attention), the file whose sha256 (e78b729b..c6d6f) is in the fixture header. TRANSCRIPT, re-extractable with --dump
  • catches — which upstream code was run
  • cannot — any revision handle: the wheel carries NO git revision, so the sha256 is the only one available and this fixture is tied to that hash rather than to a commit

vendor/dormouse-fused/crates/burn-rmsnorm/tests/fixtures/rmsnorm_oracle.txt

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/fixtures/rmsnorm_oracle.txt”
  • tier — a
  • target — GENERATED by tests/oracle/gen_rmsnorm_oracle.py from the two upstreams above; 9 significant digits of the f32 they produced. Do not hand-edit - a hand-edited golden is exactly what tier (a) exists to replace
  • catches — carries the right answers AND the four WRONG formulas as separate columns, so every margin in rmsnorm_oracle.rs is measured rather than assumed
  • cannot — -

vendor/dormouse-fused/crates/burn-rmsnorm/src/lib.rs

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/src/lib.rs”
  • tier — d
  • target — in-file scalar f64 loop over host memory in forward_matches_scalar_reference (an independent formulation, not the tensor chain restated)
  • catches — the tensor path against a host-side loop on 3x4x8 with a non-constant gain
  • cannot — the fused CUDA arm (the scalar loop is the CPU path’s oracle only); the tolerance there (1e-4 relative) is ~1000x looser than the tier-(a) test’s 1e-5, which is the reason the tier-(a) test exists

vendor/dormouse-fused/crates/burn-rmsnorm/tests/rmsnorm_kernel_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/rmsnorm_kernel_cuda.rs”
  • tier — a
  • target — the SAME two upstreams the tensor path is compared against, via the SAME generated fixture tests/fixtures/rmsnorm_oracle.txt (torch.nn.functional.rms_norm -> torch.rms_norm, ATen torch::rms_norm, torch==2.14.0+cpu, pytorch/pytorch v2.14.0; and fla.modules.layernorm.rms_norm_ref, flash-linear-attention==0.5.2, fla-org/flash-linear-attention, sha256(fla/modules/layernorm.py)=e78b729b..c6d6f) - here measured against the FUSED CUDA KERNEL’s own output (src/fused.rs), on a bare (non-autodiff) Device::cuda(0), which is the one shape on which it runs at all
  • catches — the kernel’s own arithmetic on all 12 fixture cases at the sibling’s TOL_REL 1e-5, unloosened: eps inside the sqrt, the per-feature gain index, the /d of the reduction, and the strided tail at d=1/2/13. PLUS REACHABILITY, which is the part no other file owns: the seam counters (asked and ran) are pinned around every single case, so a silent decline to the tensor path fails the test instead of re-testing the tensor path under a file whose name says otherwise; and the trainer’s autodiff shape and its valid() eval snapshot are gates on the norm=0/N claim
  • cannot — the trainer’s exact cubecl runtime: this target compiles in the burn-fused workspace, where the root [patch.crates-io] does not apply, so the kernel runs on the registry cubecl 0.11.0-pre.4 while the trainer runs the vendored fork; the BACKWARD (fused.rs returns a fresh plain Tensor::empty, so were it ever reached from an autodiff input the arm would carry no gradient - the burn_gdn2 defect, and the reason the refusal is the thing to preserve); the bf16/f16 arms, which fused.rs declines by dtype; WHETHER either upstream faithfully transcribes arXiv:1910.07467, whose AUTHORS SHIP NO CODE
  • waiver — -

vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/mutate_fused_kernel.sh

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/mutate_fused_kernel.sh”
  • tier — x
  • target — n/a - it runs the crate’s own CUDA tests against deliberately wrong fused kernels
  • catches — that the KERNEL-path oracle can fail: five mutants of src/fused.rs (eps outside the sqrt / dropped / hardcoded to 1.1920929e-7, the per-feature gain collapsed to w[0], the reduction’s /d dropped), each of which turns at least one test red. It snapshots and restores the source, traps on every exit path and md5-compares at the end
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-rmsnorm/tests/fused_kernel_gate.rs

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/fused_kernel_gate.rs”
  • tier — a
  • target — a scalar f64 definition of x / sqrt(mean(x^2) + eps) * gain written out in the file (NOT a transcription of the crate, and NOT the tier-(a) torch/fla fixture); a CONTROL through this crate on ndarray against the same f64 reference so a pass cannot come from the reference agreeing with itself
  • catches — that the fused CUDA arm is TAKEN, read from the seam counter rather than assumed, and that its answer matches f64 to 1e-5 relative at mean-squares spanning 1e-4..1e2 (measured worst 1.168e-7 over 84 outputs, asked 6 skipped 0, 2026-09-30) so the eps question is decided; that the backward-less arm DECLINES on an autodiff device (the norm=0/N of the trainer logs, as a gate); and that d<4 DECLINES and its fallback is correct
  • cannot — the BACKWARD (rmsnorm_cuda returns a fresh Tensor::empty with raw handles in, so were it reached from an autodiff input the arm would carry no gradient - the burn_gdn2 failure mode, and the reason the dispatch refusal is the thing to preserve); d in {1,2,3} (REFUSED - the launch does not execute its trailing cubes there, see tests/d2_isolate.rs, and MIN_FUSED_D=4 is a measured envelope not a derived one); the torch/fla columns, which rmsnorm_kernel_cuda.rs owns; the trainer’s cubecl runtime (this target compiles in the burn-fused workspace, where the root [patch.crates-io] does not apply, so the kernel runs on the registry cubecl 0.11.0-pre.4)
  • waiver — -

vendor/dormouse-fused/crates/burn-rmsnorm/tests/lower_probe.rs

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/lower_probe.rs”
  • tier — x
  • target — n/a - it compares no value against any reference. Its rungs assert only that a kernel LOWERED and wrote the value the rung itself predicts, which is what separates “failed to compile” from “computed something else”
  • catches — WHICH PART of the kernel fails to lower, one rung at a time. This is the bisect that retired the 34c5631/9ac0377 diagnosis: p2 (shared alloc, comptime size, one write, one barrier, one read) LOWERS, p4 (a sync_cube inside a runtime-bounded while, no shared at all) LOWERS, p6 (the same kernel, reduction serialised) LOWERS at 1.72e-7, p9 (the halving while with NO barrier anywhere) FAILS, p5/p7 (the halving while) FAIL, p10 (the same reduction as for k in 0..log_threads over a comptime trip count) LOWERS at 1.72e-7
  • cannot — the kernel’s NUMERICS - it is a lowering instrument, not a correctness one, and its per-rung tolerance is 1e-4 on purpose; p5/p7/p9 are #[ignore]d reproducers that FAIL on purpose, and each rung must be run in its own process (--exact <rung>) because a launch failure poisons the CUDA context for the rest of the binary
  • waiver — -

vendor/dormouse-fused/crates/burn-rmsnorm/tests/d2_isolate.rs

Section titled “vendor/dormouse-fused/crates/burn-rmsnorm/tests/d2_isolate.rs”
  • tier — x
  • target — n/a - it compares no value against any reference. It is an EXCLUSION table: the point is to prove which suspects are NOT the cause by making them reproduce or not reproduce
  • catches — that the SECOND defect is not the kernel body, not the grid, not a runtime grid count, not the block size and not a readback race, but the OUTPUT TENSOR’S SHAPE. Same 4-line kernel (out[CUBE_POS_X] = 1.0, no shared memory, no barrier), same 4-cube grid, same 16-element length: out [8,2] runs 2 cubes and [16,1] runs 4, [1,1] runs 1, [2,1] runs 2, [3,1] runs 3, while [1,16]/[2,8]/[4,4]/[4,1]/[5,1] run 4. CubeDim 32..1024 truncate identically; four reads agree and an explicit client.sync() changes nothing
  • cannot — the RULE behind that shape dependence. It lives inside cubecl’s launch path and is NOT isolated; 12 shape samples did not yield it and it is not guessed at. MIN_FUSED_D = 4 in src/fused.rs is the measured envelope, not a law, and the mechanism is an open follow-up rather than a closed question
  • waiver — -

vendor/dormouse-fused/crates/burn-gdn2/tests/fused_launch_count.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/fused_launch_count.rs”
  • tier — x
  • target — n/a - it counts CUDA launches per forward via alloc_trace::fused_launches_per_call(), it compares no value to any reference
  • catches — the claim that the module path issues 2 kernels and the scratch path 3, which a CALL counter cannot see (fused_chunk_forward used to route through …_scratch and discard the scratch)
  • cannot — CUDA only, so tools/lib_gate.sh does not run it; the vendor GPU gate does
  • waiver — -

vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_bwd_f64.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_bwd_f64.rs”
  • tier — b
  • target — f64 forward-mode AD + full-tensor central differences over a TRANSCRIPTION of chunk_wy_forward_batched (tools/gen_bwd_f64.py, tools/fwd_mode.py), committed as tests/ref_bwd_f64.bin
  • catches — the analytic adjoint (custom node, f32) on ALL 1792 coordinates of all seven inputs; the FORWARD against the f64 transcription first, which is what bounds the transcription risk; the bar’s far side from 10 wrong formulas in ref_bwd_f64_faults.bin, three of which this shape provably cannot exercise and are named
  • cannot — a shared MISREADING of the specification, which survives any transcription; the fused CUDA kernel (CPU build); the inter-chunk half of the adjoint (one chunk, so no BK2 and no d_k_bptt/d_e_bptt/d_s_shift); any two-chunk shape, where the forward disagrees with the transcription at 8.3e-1
  • waiver — TIER (b) NOT (a): the two methods are independent of each other, so the DERIVATIVE is not a transcription, but the FORWARD is. The words bit-exact/bit-for-bit are not used about it.

vendor/dormouse-fused/crates/burn-gdn2/tests/fused_adjoint_f64.rs

Section titled “vendor/dormouse-fused/crates/burn-gdn2/tests/fused_adjoint_f64.rs”
  • tier — b
  • target — tests/ref_bwd_f64.bin - forward-mode AD in f64 over a transcription of the forward, cross-checked inside the generator against full-tensor central finite differences (the two agree to 1.2e-12)
  • catches — a wrong adjoint, a MISSING GRADIENT, a dropped term, a transposed contraction, a sign error, and a gradient of a different function - none of which any arm-vs-arm comparison can see, because both sides of those are our own forward differentiated by the same framework and a misreading cancels. Demonstrated red: negating one term’s expected gradient turns it red. The forward is pinned separately at 1.4e-7 by tests/autodiff_bwd_f64.rs
  • cannot — CUDA only (required-features = [cuda, autodiff]), so tools/lib_gate.sh does not run it; the vendor GPU gate does. It is the first measurement in this project that any fused-adjoint kernel has been compared to anything at all - fused_chunk_verify.rs compared the tensor adjoint against the tensor path
  • waiver — -

vendor/dormouse-fused/crates/burn-engram/src/hasher.rs

Section titled “vendor/dormouse-fused/crates/burn-engram/src/hasher.rs”
  • tier — b
  • target — a port of NgramHashMapping._get_ngram_hashes from deepseek-ai/Engram (arXiv:2601.07372), the official reference
  • catches — reclassified 2026-09-30 from (d): my bulk pass went by ‘no oracle keyword’ and missed the module doc’s ‘Port of … from the official reference’. A hand port of named upstream code is a TRANSCRIPTION, which is tier (b) - not the same as comparing our code to itself
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-engram/tests/engram_oracle.rs

Section titled “vendor/dormouse-fused/crates/burn-engram/tests/engram_oracle.rs”
  • tier — a
  • target — RAN, not transcribed: deepseek-ai/Engram@main engram_demo_v1.py (EngramModule.forward), executed on CPU 2026-09-29 and vendored under tests/oracle/ so the gate needs no network
  • catches — reclassified 2026-09-30 from (b): the bulk declaration went by filename and this is a TEST that RUNS the official code, not a transcription. The gate agrees to 1e-5 on the gate, 2e-5 on the module forward, 1e-5 on the conv, EXACTLY on the prime ladder, and the_claim proves the tolerance is not wider than the fixture’s discriminating power. This is the oldest tier-(a) row in the tree - it predates the doctrine, and it sat unregistered for a month while red
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-engram/tests/oracle/engram_demo_v1.py

Section titled “vendor/dormouse-fused/crates/burn-engram/tests/oracle/engram_demo_v1.py”
  • tier — a
  • target — the upstream code this generator RUNS; versions/sha are in the fixture header
  • catches — DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong)
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-engram/tests/oracle/gen_engram_oracle.py

Section titled “vendor/dormouse-fused/crates/burn-engram/tests/oracle/gen_engram_oracle.py”
  • tier — a
  • target — the upstream code this generator RUNS; versions/sha are in the fixture header
  • catches — DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong)
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/bf16_matmul.rs

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/bf16_matmul.rs”
  • tier — x
  • target — none - it CHARACTERISES what bf16 does on this backend (measured), rather than checking a value against any reference
  • catches — reclassified 2026-09-30 from (d): a characterisation is not a self-comparison, and filing it (d) would let a reader count it as evidence of fidelity. What it IS worth is in the file
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/self_checks.rs

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/self_checks.rs”
  • tier — d
  • target — in-crate: an independent formulation or a counter, NOT an external reference
  • catches — DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong)
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/zero_grad.rs

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/zero_grad.rs”
  • tier — d
  • target — in-crate: an independent formulation or a counter, NOT an external reference
  • catches — DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong)
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-sct/examples/bench_gpu.rs

Section titled “vendor/dormouse-fused/crates/burn-sct/examples/bench_gpu.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-sct/examples/bench_ops.rs

Section titled “vendor/dormouse-fused/crates/burn-sct/examples/bench_ops.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-sct/examples/gpu_check.rs

Section titled “vendor/dormouse-fused/crates/burn-sct/examples/gpu_check.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-sct/examples/gpu_mm.rs

Section titled “vendor/dormouse-fused/crates/burn-sct/examples/gpu_mm.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-sct/examples/gpu_svd.rs

Section titled “vendor/dormouse-fused/crates/burn-sct/examples/gpu_svd.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-sct/examples/gpu_svd2.rs

Section titled “vendor/dormouse-fused/crates/burn-sct/examples/gpu_svd2.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-sct/examples/mm_probe.rs

Section titled “vendor/dormouse-fused/crates/burn-sct/examples/mm_probe.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-sct/tests/cuda_retract.rs

Section titled “vendor/dormouse-fused/crates/burn-sct/tests/cuda_retract.rs”
  • tier — d
  • target — in-crate: an independent formulation or a counter, NOT an external reference
  • catches — DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong)
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/examples/gpu_check.rs

Section titled “vendor/dormouse-fused/crates/burn-spectral/examples/gpu_check.rs”
  • tier — d
  • target — in-crate: a CUDA availability/shape check, asserted rather than timed
  • catches — reclassified 2026-09-30 from (x): 2 asserts. Named like a probe, used like a test
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/examples/infer_bench.rs

Section titled “vendor/dormouse-fused/crates/burn-spectral/examples/infer_bench.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/examples/linear_timing.rs

Section titled “vendor/dormouse-fused/crates/burn-spectral/examples/linear_timing.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/examples/moe_flops.rs

Section titled “vendor/dormouse-fused/crates/burn-spectral/examples/moe_flops.rs”
  • tier — d
  • target — in-crate: MoE FLOP accounting against the same accounting computed another way
  • catches — reclassified 2026-09-30 from (x): carries an assert, so it asserts something. 1 assert is few but not none
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/examples/moe_timing.rs

Section titled “vendor/dormouse-fused/crates/burn-spectral/examples/moe_timing.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/examples/moe_timing2.rs

Section titled “vendor/dormouse-fused/crates/burn-spectral/examples/moe_timing2.rs”
  • tier — x
  • target — none - a benchmark or a manual probe; it asserts no value against any reference
  • catches — reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/examples/tsct_diag.rs

Section titled “vendor/dormouse-fused/crates/burn-spectral/examples/tsct_diag.rs”
  • tier — d
  • target — in-crate: does TSCT actually learn - a mini-GPT on a char-level task, dense vs SpectralLinear vs SpectralMoE at a matched parameter budget
  • catches — reclassified 2026-09-30 from (x): a diagnostic that answers ‘does this mechanism learn’ is a self-comparison, which is exactly tier (d). 14 asserts
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/src/lib.rs

Section titled “vendor/dormouse-fused/crates/burn-spectral/src/lib.rs”
  • tier — b
  • target — arXiv:2602.21545v3 Appendix D.3, which prints the PolarExpress schedule ending at exactly (1.875, -1.25, 0.375); v1 and v2 print no NS coefficients at all
  • catches — reclassified 2026-09-30 from (d): the coefficients are hand-verified against a named appendix of a pinned version, which is a transcription of a primary source. NOT tier (a): no upstream code was executed
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/src/moe_fused.rs

Section titled “vendor/dormouse-fused/crates/burn-spectral/src/moe_fused.rs”
  • tier — d
  • target — in-crate: the fused token-choice MoE forward+backward against the same maths in tensor ops, and assert-based self-checks
  • catches — reclassified 2026-09-30 from (x) a SECOND time: I filed it as an example/benchmark by PATH, and it is a SOURCE FILE - the fused CUDA MoE kernel - carrying 49 asserts. Assert count is the honest discriminator, not the path
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/README.md

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/README.md”
  • tier — x
  • target — none - provenance and re-run instructions for the oracle directory above
  • catches — -
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/final_numbers.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/final_numbers.py”
  • tier — a
  • target — a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline
  • catches — DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/illconditioned_sweep.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/illconditioned_sweep.py”
  • tier — a
  • target — a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline
  • catches — DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/measure_algorithms.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/measure_algorithms.py”
  • tier — a
  • target — a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline
  • catches — DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/pin_findings.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/pin_findings.py”
  • tier — a
  • target — a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline
  • catches — DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/run_polar_express.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/run_polar_express.py”
  • tier — a
  • target — a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline
  • catches — DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/run_targets_2_and_3.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/run_targets_2_and_3.py”
  • tier — a
  • target — a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline
  • catches — DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/gram_newton_schulz_README.md

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/gram_newton_schulz_README.md”
  • tier — a
  • target — VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit
  • catches — that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/kellerjordan_muon_post.html

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/kellerjordan_muon_post.html”
  • tier — a
  • target — VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit
  • catches — that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/kellerjordan_newtonschulz5.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/kellerjordan_newtonschulz5.py”
  • tier — a
  • target — VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit
  • catches — that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/novelai_polarexpress.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/novelai_polarexpress.py”
  • tier — a
  • target — VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit
  • catches — that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/novelai_polarexpress3.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/novelai_polarexpress3.py”
  • tier — a
  • target — VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit
  • catches — that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/polar_express.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/polar_express.py”
  • tier — a
  • target — VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit
  • catches — that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/polar_express_LICENSE

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/polar_express_LICENSE”
  • tier — a
  • target — VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit
  • catches — that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/polar_express_README.md

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/polar_express_README.md”
  • tier — a
  • target — VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit
  • catches — that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/audit_2026_10_01.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/audit_2026_10_01.py”
  • tier — b
  • target — TRANSCRIPTION of vendor/dormouse-fused/crates/burn-spectral/src/lib.rs:208-341 (the retraction, the power iteration, the Stiefel metric) re-expressed in torch; a REFERENCE only where it says LAPACK. Wheel pinned: torch 2.14.0+cpu, numpy 2.5.2, python 3.12.14, CPU, f64 unless a line says f32. The coefficients own provenance is arXiv:2602.21545v3 Appendix D.3, as cited in lib.rs
  • catches — that the transcription reproduces the claims the Rust COMMENTS make: p(1)=1 and p’(1)=0, the basin edge sqrt(7/3)=1.5275, the Rayleigh estimate error as a function of how flat the spectrum is, and the retracted Gram is I. Findings 1-3 of docs/reviews/spectral-audit-2026-10-01.md were produced by it
  • cannot — anything about the Rust itself - it is a transcription, not the code; f32 (it is f64); CUDA; the REACHABILITY of the class-B-2 hole, which is sec4_fixed.py and sec4c_tolerance.py
  • waiver — R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column.

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec4_fixed.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec4_fixed.py”
  • tier — b
  • target — the same transcription restricted to one question: can the sigma_max estimate put the NS input OUTSIDE the basin? M is built as the Cholesky factor of a KNOWN Gram (M M^T = G, asserted in the script, not assumed) so lambda_1 is exact and no eigenbasis search is involved
  • catches — that the class-B-2 hole is LATENT and not live: 0 of 4000 random Wishart draws and 0 of the adversarial-drift rows land outside the basin, worst prescaled sigma_max 1.1549 against an edge of 1.5275
  • cannot — the diverging case itself (that is sec4c_tolerance.py); f32; CUDA; anything about the Rust
  • waiver — R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column.

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec4c_tolerance.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec4c_tolerance.py”
  • tier — b
  • target — the same transcription with the spectrum built IN CLOSED FORM (G = lam_rest*I + (1-lam_rest) u1u1^T + (l2-lam_rest) u2u2^T, top eigenvector at a controlled overlap delta with the all-ones direction), so l2/l1 is known rather than searched
  • catches — that at l2/l1 = 0.5/0.3/0.1/0.01 with delta = 1e-9 the 3-iteration retraction returns f64 max|out| ~ 3.3e+60 and inf in f32 (f32 max is 3.4028e+38) - the ‘inf in the trainer dtype’ of class B-2; and that a Frobenius prescale cannot diverge on the same factors (it lands at 0.95 and 0.61)
  • cannot — reachability (that is sec4_fixed.py); f64 for anything but the overflow, which is where f32 differs; CUDA; anything about the Rust
  • waiver — R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column.

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec4d_guard.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec4d_guard.py”
  • tier — b
  • target — the same transcription plus the ONE-LINE GUARD it was written to price: sigma_used = max(sigma_est, ||X||_F / (1.05*sqrt(7/3))), which Cauchy-Schwarz makes provably in-basin for every input
  • catches — that the guard is WRONG as a fix, which is what the B-2 gate records: it engaged on 21 of 21 cases INCLUDING all four well-behaved [64,4] Gaussians and the orthonormal [768,64] (sigma_max = 1 exactly, ||X||_F = 8, so ||X||_F/1.604 = 4.99 beats a correct estimate of 1). It converges - to the wrong place, silently
  • cannot — the sigma_max consequence (the printed columns are entry magnitudes, not sigma_max; that number is docs/papers/spectral-reference.md 3.4); CUDA; anything about the Rust
  • waiver — R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column.

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec5_6b.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec5_6b.py”
  • tier — b
  • target — the transcription AND LAPACK: torch.linalg.polar on the same factor, i.e. the DEFINITION of a polar factor rather than another arm of ours. LAPACK is a third-party implementation of the definition, not the mechanism’s authors
  • catches — class B-1: the per-entry ||U^T U - I|| of a 3-ITERATION retraction against the trainer’s one-way 1e-3 latch, at spectral spreads 0.3/0.1/0.01 = 8.3e-4 / 3.3e-2 / 8.5e-2, i.e. 0.8x / 32.6x / 85.0x the latch; and that 5 iterations survives a 10:1 spread. Also the section-5 fix: the first version measured svdvals on a WIDE matrix and read a rank deficiency as a result
  • cannot — whether any run on record ever reaches those spreads - NO run has been instrumented for the factor’s spectrum, which is the reason this is class B and not a defect; CUDA; the batched arm
  • waiver — R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column.

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/gate_dryrun.py

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/gate_dryrun.py”
  • tier — b
  • target — a numpy dry-run of the FOUR gates this audit landed, at the Rust’s own dtype (f32), written before the cargo slot because a cold build of vendor/dormouse-fused costs ~20 min of queue
  • catches — that the gates’ LOGIC is right before they reach cargo. It found all three fixture defects section 11.1 of the audit records: the Gram passed where the code estimates on a FACTOR (so the estimate came back correct over the finding), a ‘basis’ that was 548:1 degenerate before any spread, and a log-spaced fixture that could not have refuted the comment
  • cannot — the Rust itself - no compile error and no wrong dtype is visible here; the production CANONICAL TRANSPOSE (lib.rs:211-215), which it had to be taught or it forms the [768,768] Gram and reproduces by accident exactly the Frobenius-prescale failure this audit disproves
  • waiver — R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column.

vendor/dormouse-fused/crates/burn-spectral/tests/oracle/falsify.sh

Section titled “vendor/dormouse-fused/crates/burn-spectral/tests/oracle/falsify.sh”
  • tier — x
  • target — none - it runs the crate’s own tests against deliberately perturbed code and asserts nothing about an external reference
  • catches — that each gate turns RED on the mutation it exists to catch, on its OWN assertion and not merely on a non-zero exit, and that the restore is byte-identical by sha256. It is the evidence that the gates are gates
  • cannot — anything about the algorithm: an EQUIVALENT mutation cannot fail, and section B’s first version was exactly that (both arms of a bit-identity perturbed together, which stays identical by construction)
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/optim/muon_plus.py

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/optim/muon_plus.py”
  • tier — a
  • target — RAN, not transcribed: K1seki221/MuonPlus @ 8a9ace123afedaab8ba75ea0b19315594ae1da7c (last push 2026-02-26) - the Muon+ AUTHORS’ own implementation, named in their paper’s abstract. Pinned and sha256-checked by gen_oracle.py, which REFUSES to write a fixture if the pin is rotated
  • catches — the NS coefficients and the polar operator against the authors’ code rather than against a reading of the paper; also adjust_lr_for_muon (muon_plus.py:245-252), which FALSIFIED a comment in our own lib.rs:456-479 - it says the max(1,·) follows the Muon+ implementation, and the implementation has no max
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/optim/polar_express.py

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/optim/polar_express.py”
  • tier — a
  • target — RAN: the PolarExpress authors’ own generator, from NoahAmsel/PolarExpress @ 71cc379
  • catches — that App. D.3’s printed schedule is NOT reproducible from the authors’ repository (~6e-3 from entry 1) - a finding about the paper, not about us
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/muon_oracle.bin

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/muon_oracle.bin”
  • tier — a
  • target — the f32 the authors’ code produced, at 9 significant digits; gen_oracle.py regenerates it byte-identically
  • catches — a wrong coefficient, a wrong composition order, and a transposed normalisation axis - all demonstrated red by tests/oracle/falsify.sh
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/muon_oracle.rs

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/muon_oracle.rs”
  • tier — a
  • target — the four artifacts above; NO feature gate and no Python at test time, because the expected values are committed bytes
  • catches — a wrong NS coefficient (last digit), a wrong ColRow composition order (2.54e-1 on the col_row cases), and a transposed norm_col axis (O(1)). One mutation is EXPECTED TO STAY GREEN - the eps floor - and the test says why, because that is a property of the FIXTURE and stating it is more useful than a red line nobody can act on
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/falsify.sh

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/falsify.sh”
  • tier — x
  • target — none - it runs the crate’s own tests against deliberately perturbed code, and asserts nothing itself
  • catches — that the oracle CAN fail: five perturbations, each reverted, with the tree restored byte-identical
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/PROVENANCE.md

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/PROVENANCE.md”
  • tier — x
  • target — repo/commit/date/sha256 table for the pinned upstream
  • catches — -
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/gen_oracle.py

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/gen_oracle.py”
  • tier — a
  • target — a SCRIPT that RUNS the pinned upstream and emits muon_oracle.bin; it refuses to write if the upstream sha256 is rotated, so a silent upstream change cannot produce a new green
  • catches — the provenance of the (a) rows above: the pin check is itself demonstrated red by falsify.sh, which mutates the file and gets ‘PIN ROTATED’ with both hashes named
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/measure_ns_snr.py

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/measure_ns_snr.py”
  • tier — a
  • target — a SCRIPT that RUNS the pinned upstream and emits muon_oracle.bin; it refuses to write if the upstream sha256 is rotated, so a silent upstream change cannot produce a new green
  • catches — the provenance of the (a) rows above: the pin check is itself demonstrated red by falsify.sh, which mutates the file and gets ‘PIN ROTATED’ with both hashes named
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/transcript.txt

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/transcript.txt”
  • tier — x
  • target — captured output of the scripts beside it; evidence, not a test
  • catches — -
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/init.py

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/init.py”
  • tier — a
  • target — a SCRIPT that RUNS the pinned upstream and emits muon_oracle.bin; it refuses to write if the upstream sha256 is rotated, so a silent upstream change cannot produce a new green
  • catches — the provenance of the (a) rows above: the pin check is itself demonstrated red by falsify.sh, which mutates the file and gets ‘PIN ROTATED’ with both hashes named
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/optim/init.py

Section titled “vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/optim/init.py”
  • tier — a
  • target — a SCRIPT that RUNS the pinned upstream and emits muon_oracle.bin; it refuses to write if the upstream sha256 is rotated, so a silent upstream change cannot produce a new green
  • catches — the provenance of the (a) rows above: the pin check is itself demonstrated red by falsify.sh, which mutates the file and gets ‘PIN ROTATED’ with both hashes named
  • cannot — -
  • waiver — -

vendor/dormouse-fused/crates/burn-kda/tests/kda_oracle.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/kda_oracle.rs”
  • tier — a
  • target — RAN, not transcribed: fla-org/flash-linear-attention@9f38d24980c46d46bd38614e743cdacd21906578, fla/ops/kda/gate.py::naive_kda_gate + naive_kda_lowerbound_gate and fla/ops/kda/naive.py::naive_recurrent_kda + naive_chunk_kda, executed on CPU 2026-09-30 (torch 2.14.0+cpu, einops 0.8.2). FLA’s own pure-PyTorch references, extracted from the pinned bytes and exec’d, never re-typed. See tests/oracle/PROVENANCE.md
  • catches — the RUNNING K3 decay form character-for-character incl. g_min=-5 (6 cases); Eq 1 term by term incl. the carried state (3 shapes, one GVA); the chunked WY construction on BOTH gdn2 chunk arms (3 cases); the output gate is sigmoid; the read scale is the ONLY difference between FLA’s two fixture rows. RED ON PURPOSE: the Kimi-Linear softplus placement (src/lib.rs:268) and the missing read scale (src/lib.rs:646,653, fused.rs:9). 3 reds are the only failures in the file
  • cannot — the a_log clamp (src/lib.rs:293) - no source has one, so no fixture case carries an A outside [-10, 20] and a mutant that WIDENS the clamp is invisible here; the recurrent path’s read scale, which has no scale ARGUMENT to fix (kda_step/forward_recurrent take none) so the chunked reds compare the MECHANISM, not the wiring; anything about model QUALITY
  • waiver — the two pinned upstream .py files carry no github.com URL because a provenance header would mean editing an upstream file; the URL and the enforced sha256 are in tests/oracle/PROVENANCE.md, and gen_kda_oracle.py exits 2 on PIN ROTED

vendor/dormouse-fused/crates/burn-kda/tests/oracle/gen_kda_oracle.py

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/oracle/gen_kda_oracle.py”
  • tier — a
  • target — the upstream it runs (flash-linear-attention@9f38d249, torch 2.14.0+cpu + einops, CPU 2026-09-30). It is the GENERATOR, so it asserts nothing at runtime; its three vacuity guards are what make the fixture non-vacuous and it exits 3 without writing if any fails
  • catches — nothing at runtime (it is not run by cargo). Run by hand: the sha256 of both pinned files, upstream’s recurrent vs chunk references agreeing with each other, the softplus cases separating the two placements of exp(A), and FLA’s executed reference reproducing the alpha=0.0771 that src/lib.rs:58 publishes
  • cannot — the crate’s own formulas - it produces the expected values, it does not test them; that is tests/kda_oracle.rs

vendor/dormouse-fused/crates/burn-kda/tests/fixtures/kda_oracle.txt

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/fixtures/kda_oracle.txt”
  • tier — a
  • target — GENERATED by tests/oracle/gen_kda_oracle.py by RUNNING fla-org/flash-linear-attention@9f38d249’s four pure-PyTorch KDA references on CPU (torch 2.14.0+cpu, einops 0.8.2), 2026-09-30. 12 cases: 6 decay gate, 3 recurrent (each at scale 1.0 AND at FLA’s own K**-0.5 default), 3 chunked WY (each at both scales). 9 significant digits, which round-trips f32 exactly
  • catches — nothing by itself; it is the expected-value file for tests/kda_oracle.rs
  • cannot — the crate’s own formulas

vendor/dormouse-fused/crates/burn-kda/tests/oracle/upstream/fla_ops_kda_gate.py

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/oracle/upstream/fla_ops_kda_gate.py”
  • tier — a
  • target — VERBATIM fla-org/flash-linear-attention@9f38d24980c46d46bd38614e743cdacd21906578 fla/ops/kda/gate.py, sha256 7ea46d62149b8e28e0827e070fee327576de783cb981e3b855182f2b8198c16e. Carries the line ‘This file is modified and supported by the Moonshot AI Team’ (gate.py:8): the KDA decay gate is Moonshot’s own file, not a third party’s
  • catches — nothing by itself; the four reference functions are EXTRACTED from its bytes by gen_kda_oracle.py::extract_def and exec’d, never re-typed
  • cannot — the crate’s own formulas. It is not importable as a module (triton at module scope), which is why extraction is used rather than an import
  • waiver — no github.com URL in the file because a provenance header would mean editing an upstream file; the URL and the enforced sha256 are in tests/oracle/PROVENANCE.md

vendor/dormouse-fused/crates/burn-kda/tests/oracle/upstream/fla_ops_kda_naive.py

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/oracle/upstream/fla_ops_kda_naive.py”
  • tier — a
  • target — VERBATIM fla-org/flash-linear-attention@9f38d24980c46d46bd38614e743cdacd21906578 fla/ops/kda/naive.py, sha256 60a32285d4b67068ff633b48bbe8ab31028066d24f00d27e12199a88fc73f016. naive_recurrent_kda and naive_chunk_kda, the correctness oracle FLA’s own tests compare its Triton KDA kernels against (tests/ops/test_kda.py:20)
  • catches — nothing by itself; both functions are EXTRACTED from its bytes and exec’d, never re-typed
  • cannot — the crate’s own formulas
  • waiver — no github.com URL in the file because a provenance header would mean editing an upstream file; the URL and the enforced sha256 are in tests/oracle/PROVENANCE.md

vendor/dormouse-fused/crates/burn-kda/tests/kda_param_grads_cuda.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/kda_param_grads_cuda.rs”
  • tier — x
  • target — INSTRUMENT, not an oracle: it asserts GRADIENT ARRIVAL (all 11 groups non-zero, finite) - value fidelity is the two-chunk f64 oracle’s job, see ref_bwd_f64_carry.bin (gen_bwd_f64.py, oracle error 2.3e-12). ALSO cross-checks the fused-vs-central-difference consistency: that reference is derived from the same forward by construction, which is exactly why this row is an instrument and not a tier f64 gradient fixture ref_bwd_f64_carry.bin, GENERATED by tests/oracle/gen_bwd_f64.py (f64 NumPy, oracle error 2.3e-12, c305ec5) PLUS a central difference of the fused forward itself (proves adjoint CONSISTENCY, not formula correctness - formula correctness lives in the tier-(a) kda_oracle.txt row) plus a CPU-autodiff cross-check of the three post-op parameters at 2e-7. Falsified by a detach() at cuda_dispatch.rs:449 killing 8 of 11 parameter groups, restored sha256-identical
  • catches — all 11 KDA parameter groups receive non-zero, finite gradients on the trainer backend at trainer shapes
  • cannot — the fused adjoint NUMERICSW beyond consistency (the two-chunk f64 oracle carries that); determinism of the decay path beyond the run-to-run amax record

vendor/dormouse-fused/crates/burn-kda/tests/kda_rope.rs

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/kda_rope.rs”
  • tier — a
  • target — Tier (a) by its own header: RoPE on the KDA q/k path against FLAs OWN rotary reference, pinned as a separate file (tests/oracle/upstream/fla_modules_rotary.py) on purpose, so the pin cannot rot silently into a transcription
  • catches — the q/k rotary application on the KDA path against the authors code
  • cannot — whatever the rope test does not assert; see its header

vendor/dormouse-fused/crates/burn-kda/tests/oracle/upstream/fla_modules_rotary.py

Section titled “vendor/dormouse-fused/crates/burn-kda/tests/oracle/upstream/fla_modules_rotary.py”
  • tier — a
  • target — VERBATIM fla-org/flash-linear-attention upstream rotary module, sha256 6e9d1051751257370fd5f4f95ed4798adab642e1c59a9c0a3540adab440c5115. Carries the upstream MIT header (Copyright 2023-2026 Songlin Yang, Yu Zhang, Zhiyuan Li)
  • catches — nothing by itself; the reference functions are extracted/execd

This page is a rendering of the register. The artifact tools/oracle_gate.py reads is the tab-separated ORACLE-TIERS.tsv itself.

ACTUALLY compared against. Read by tools/oracle_gate.py; the prose form is

Section titled “ACTUALLY compared against. Read by tools/oracle_gate.py; the prose form is”

docs/protocols/ORACLE.md. Tiers are ADR-0020’s: (a) AUTHORS (b) TRANSCRIPTION

Section titled “docs/protocols/ORACLE.md. Tiers are ADR-0020’s: (a) AUTHORS (b) TRANSCRIPTION”

(c) TRANSCRIPTION-OF-TRANSCRIPTION (d) NOTHING. (x) = not a correctness test.

Section titled “(c) TRANSCRIPTION-OF-TRANSCRIPTION (d) NOTHING. (x) = not a correctness test.”

“target” is the thing the expected value came from. If it names a function in

Section titled ““target” is the thing the expected value came from. If it names a function in”

this fork, the comparison is arm-vs-arm and the tier is (d), whatever the

Section titled “this fork, the comparison is arm-vs-arm and the tier is (d), whatever the”

test’s own name says. That single column is the whole point of the file.

Section titled “test’s own name says. That single column is the whole point of the file.”

tab-separated. Waive a real violation by putting a reason in the LAST column;

Section titled “tab-separated. Waive a real violation by putting a reason in the LAST column;”

an empty waiver is a FAIL. Waived rows print as DEBT on every run, so the debt

Section titled “an empty waiver is a FAIL. Waived rows print as DEBT on every run, so the debt”

shows up in a diff instead of in somebody’s memory.

Section titled “shows up in a diff instead of in somebody’s memory.”

Generated by tools/gen_oracle_tiers.py - do not hand-edit; tab-separated files

Section titled “Generated by tools/gen_oracle_tiers.py - do not hand-edit; tab-separated files”

2026-09-30: rows for the six “refs” taps were INSERTED BY HAND directly under

Section titled “2026-09-30: rows for the six “refs” taps were INSERTED BY HAND directly under”

this header, against the instruction above, on purpose: tools/gen_oracle_tiers.py

Section titled “this header, against the instruction above, on purpose: tools/gen_oracle_tiers.py”

and this file are desynced by another lane and regenerating has destroyed 22 rows

Section titled “and this file are desynced by another lane and regenerating has destroyed 22 rows”

once. The generator is still the authority for every OTHER row. The reasoning,

Section titled “once. The generator is still the authority for every OTHER row. The reasoning,”

and the per-tap “does a runnable reference exist” answers behind these rows, are

Section titled “and the per-tap “does a runnable reference exist” answers behind these rows, are”

docs/archive/research/tier-a-references.md.

Section titled “docs/archive/research/tier-a-references.md.”

file tier target catches cannot waiver

── burn-dspark: tier (a), the first time DeepSeek’s DSpark loss was ever RUN here

Section titled “── burn-dspark: tier (a), the first time DeepSeek’s DSpark loss was ever RUN here”

vendor/dormouse-fused/crates/burn-dspark/tests/dspark_loss_oracle.rs a RAN, not transcribed: deepseek-ai/DeepSpec@005e03b81cec38b7da6399833d609ee89a2587f2 deepspec/modeling/dspark/loss.py::compute_dspark_loss, executed on CPU 2026-09-30 (torch 2.14.0+cpu, gloo world_size=1) with the OFFICIAL alphas from config/dspark/dspark_qwen3_4b.py. VALUES AND GRADIENTS: the fixture’s grad_draft/grad_conf are the same pinned source back-propagated (compute_dspark_loss(...).backward()), so no formula of ours is in the gradient path either the CE, L1/TV and confidence-BCE terms AND d/d(draft_logits), d/d(confidence_pred) against DeepSeek’s own, on 8 cases. Found and fixed 3 defects: the confidence term’s numerical space (8.1 vs 20.3 on saturated_conf), the un-detached acceptance target (L2 1.227131 vs 0.073771 on saturated_conf, 16.6x), and the BCE spelling’s kink at x==0 (2x on 10 of 14 coords of aligned_identical) the multi-anchor decay (upstream indexes it per block, we per flattened position; the generator holds A==1 rather than emit a reshape artifact); d/d(target_logits) - a frozen teacher output, which the trainer never back-propagates into; the denominator difference (den+1e-6 vs clamp_min(1.0)), real but unreachable and NOT covered by any case - no_fixture_case_reaches_the_denominator_difference is that fact executable; a FINITE-DIFFERENCE check of grad_draft, which cannot exist because the .detach() makes the returned scalar non-differentiable-consistent with its own graph (the FD converges to the LIVE target’s gradient, stably, h in [1e-3,0.2]); anything about DSpark QUALITY; the paper’s Eq. numbering vendor/dormouse-fused/crates/burn-dspark/tests/oracle/gen_dspark_loss_oracle.py a the upstream it runs (DeepSpec@005e03b, torch 2.14.0+cpu pinned - unpinned the fixture diffs by the one meta.torch_version line every few weeks). It is the GENERATOR, and it refuses to write a fixture on which any of its four guards trips: its per-term attribution missing the official scalar by >1e-4 relative; grad_draft not BIT-IDENTICAL with and without a confidence head (the .detach() property); the recorded gradients disagreeing with its own differentiated transcription by >1e-3 relative (catches a mis-indexed recording); grad_conf missing a central difference of the official scalar. A golden file its own gate calls vacuous is the defect tier (a) exists to remove its own transcription of the per-term formulas is verified against the official scalar, so a slip that cancels in the total would survive; the differentiated transcription is a TIER (b) cross-check UNDER a tier (a) number, so it cannot prove the reference - only that the recording is not mis-shaped. A finite difference cannot check grad_draft at all (see the dspark_loss_oracle.rs row) n/a vendor/dormouse-fused/crates/burn-dspark/tests/oracle/upstream/deepspec_loss.py a VERBATIM deepseek-ai/DeepSpec@005e03b81cec38b7da6399833d609ee89a2587f2 deepspec/modeling/dspark/loss.py, sha256 2e91efcaff780eec0748ef3f6f0a31374f119f609c664cc79289fdd922335328, byte-identical to the copy already at crates/dormouse-core/tests/oracle/dspark_loss.py. Re-extractable with –dump the provenance of every fixture number the arithmetic it dispatches to beyond what it spells out vendor/dormouse-fused/crates/burn-dspark/tests/oracle/upstream/deepspec_common.py a VERBATIM deepseek-ai/DeepSpec@005e03b deepspec/modeling/dspark/common.py, sha256 45273cf6c806cdb1ad24…, the DSparkForwardOutput dataclass that fixes the six input shapes the input SHAPE contract, including that block_keep_mask is Bool (& on f32 raises NotImplementedError) and eval_mask is Float - vendor/dormouse-fused/crates/burn-dspark/tests/fixtures/dspark_loss_oracle.txt a GENERATED by tests/oracle/gen_dspark_loss_oracle.py by RUNNING the upstream above; 9 significant digits of the f32 it produced. Do not hand-edit - a hand-edited golden is exactly what tier (a) exists to replace - -

── the e2m1 grid and TIE RULE: torchao’s real MX-FP4 quantizer, run

Section titled “── the e2m1 grid and TIE RULE: torchao’s real MX-FP4 quantizer, run”

vendor/dormouse-fused/crates/burn-bitnet/tests/oracle/gen_e2m1_oracle.py a RAN: pytorch/ao@3972ed015091f659418dedf12edb980a8ca56b53 - fp_format_spec.float4_e2m1_interesting_values (the OCP MX FP4 grid, spec section 5.3.2 cited by URL in that file) AND mx_tensor::to_mx, torchao’s real block quantizer, on CPU 2026-09-30 (torch 2.14.0+cpu) that the e2m1 grid is 0/.5/1/1.5/2/3/4/6 with 0.75 ABSENT and 0.5 the single subnormal; and that the format breaks ties toward the EVEN CODE at all 7 interior ties the NVFP4 block-scaled path (to_mx FLOOR vs RCEIL); any fp8/fp6 format; hardware quantizers n/a vendor/dormouse-fused/crates/burn-bitnet/tests/fixtures/e2m1_oracle.txt a GENERATED by the generator above from torchao’s own table and quantizer; 9 significant digits. Do not hand-edit the eight magnitudes, the per-tie reference answer, the round-half-to-even prediction and our ties-up answer -

── the e2m1 comparison, in the crate that OWNS the code (E2M1 lives in dormouse-core, not burn-bitnet)

Section titled “── the e2m1 comparison, in the crate that OWNS the code (E2M1 lives in dormouse-core, not burn-bitnet)”

crates/dormouse-core/tests/e2m1_oracle.rs a RAN: pytorch/ao@3972ed01 torchao’s MX-FP4 quantizer, as generated above our E2M1 == torchao’s table, 0.75 absent, one subnormal, and ActFormat::Fp4.max_value() == 6.0 (the OTHER half of the 9b343d3 defect: scaling a block onto 1); RED on the TIE RULE - fp4_round is ties-up, the format is ties-to-even, disagreeing at 4 of 7 interior ties the ternary/8-bit/4-bit-absmax paths in burn-bitnet, which have no e2m1 and no reference here

── burn-mor and burn-attnres: upstream PINNED but NOT runnable; the absence is the finding

Section titled “── burn-mor and burn-attnres: upstream PINNED but NOT runnable; the absence is the finding”

vendor/dormouse-fused/crates/burn-mor/tests/oracle/upstream/mor_expert_choice_router.py a the authors’ own MoR code, raymin0223/mixture_of_recursions@82c97f29cd140efa01f5cc4fe0de73a4c3b6ffd6 (KAIST AI / Mila / Google DeepMind, the paper’s own author list), VERBATIM. PINNED, NOT RUN: the module needs a transformers build with _static_cache_update in cache_utils, which transformers 5.17.0 does not have, so it cannot be imported here nothing by itself - it is the source a future runnable fixture must transcribe FROM, and the file that records three divergences found by READING it (our load_balancing_loss is mean((sigmoid(s)-n/T)^2) over active tokens; upstream’s token-choice balancer is sum(P_i * f_i), Switch-style, token_choice_router.py:300-306) the claim of any numeric agreement - it was never executed vendor/dormouse-fused/crates/burn-attnres/tests/oracle/upstream/attnres_README.md a MoonshotAI/Attention-Residuals@85e22310fe5ee860b4a023de312d791de8a5a5e6, VERBATIM README, PINNED. The official repository is SIX FILES: this README, the paper PDF, and 3 images - there is NO CODE upstream, so nothing can be run the authors’ own PyTorch-style pseudocode for block_attn_res, which is quotable external material and the ceiling for this tap (tier (b) transcribed from THEIR pseudocode, not from the paper’s typeset); it is where the 1/sqrt(d) divergence was found any numeric agreement vendor/dormouse-fused/crates/burn-kda/tests/cuda_gate.rs d in-crate KdaModule::forward_recurrent (per-token scan) + burn_gdn2::seam_counts chunked-WY algebra vs the exact scan; SEAM (which arm ran); nonzero parameter grad on AdBal anything in project/output (shared by all three arms); the fused CUDA kernel (this fixture DECLINES it on purpose); paper semantics vendor/dormouse-fused/crates/burn-kda/tests/ops_grad_cuda.rs d central finite differences of the ops forward (independent METHOD, not an arm) the chunk op’s adjoint on the trainer’s backend; a real q_proj.weight derivative; 8 coordinates/tensor the fused CUDA kernel; PAPER semantics vendor/dormouse-fused/crates/burn-kda/tests/fused_cuda.rs d in-crate forward_recurrent + burn_gdn2::chunk_wy_forward the fused chunk CUDA kernel forward; the chunked algebra; both DecayFn forms project/output; the fused gradient (asserts only nonzero); ragged T; the fused DECODE kernel (KDA dispatches to the tensor scan, not a kernel) vendor/dormouse-fused/crates/burn-kda/tests/bench_cuda.rs x none (nothing asserted) - vendor/dormouse-fused/crates/burn-kda/examples/bitforbit.rs d in-crate forward_recurrent + chunk_wy_forward dumps tensors for an off-tree FLA cross-check; asserts nothing itself any claim of bit-exactness - both sides are our own arms R5 (the FILENAME says bit-for-bit) is waived, not fixed: renaming collides with a [[example]] name = entry in burn-kda/Cargo.toml, two dated research logs that quote cargo run --example bitforbit, and a generated graphify report. The docstring is corrected in this lane and now says so in its first line; the RENAME is a follow-up for whoever owns burn-kda. vendor/dormouse-fused/crates/burn-kda/examples/bitforbit_cuda.rs d in-crate forward_recurrent, same tensors as the CPU dump fused chunk kernel vs the CPU-dumped scan inputs; asserts nothing itself any claim of bit-for-bit - both sides are our own arms R5 (the FILENAME) waived for the same reason as bitforbit.rs, plus Cargo.toml:35 declares name = "bitforbit_cuda" explicitly, so the rename is a Cargo edit and not a git mv. Docstring corrected here. vendor/dormouse-fused/crates/burn-kda/examples/kda_bench.rs x none (nothing asserted) - vendor/dormouse-fused/crates/burn-kda/examples/kda_step_probe.rs x none (nothing asserted) - vendor/dormouse-fused/crates/burn-gdn2/tests/alloc_probe.rs x none all 4 tests #[ignore]d; allocator counters only any correctness claim vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_chunk.rs d in-crate chunk_wy_forward (ops) + central finite differences CHUNK (custom-node forward vs per-op); GRAD (analytic adjoint vs FD, but 1 argmax coordinate per input at 5% rel) the fused CUDA kernel (CPU build); project/output; every coordinate the 7 probes do not land on vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_cuda_gate.rs d in-crate chunk_wy_forward + seam counters backend gate decision; the fused kernel reaching a Balanced graph; fused-vs-ops numerics; a wrong d_k/d_g project/output; any non-CUDA backend vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_nested_balanced.rs d in-crate, NoCheckpointing vs BalancedCheckpointing the checkpoint-strategy transposition; that the op declines a nested graph the numerics; the fused kernel vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff.rs d in-crate fused_recurrent_forward (scan) vs chunk_wy_forward; decode vs prefill CHUNK; STATE carry; prefill->decode handoff; 5 config-refusal tests project/output (used as FIXED input); the fused CUDA kernel vendor/dormouse-fused/crates/burn-gdn2/tests/b5_seam_probe.rs d hand-written host rank-5 references in the same file LAYOUT: swap_dims(3,4)/matmul/cumsum/slice/permute on rank 5 anything about the recurrence vendor/dormouse-fused/crates/burn-gdn2/tests/bench_cuda.rs d in-crate fused_recurrent_forward; fused_step directly at :204 the fused DECODE CUDA kernel, per token, state and output. NOTE: the file is named bench but :204 is a real assert!; only bench_cuda at :87 is #[ignore]d project/output; the fused CHUNK kernel vendor/dormouse-fused/crates/burn-gdn2/tests/bench_fused_bwd.rs x none times the fused adjoint and discards the result - vendor/dormouse-fused/crates/burn-gdn2/tests/bench_tracks.rs x none (nothing asserted) - vendor/dormouse-fused/crates/burn-gdn2/tests/bench_train_cuda.rs x none (nothing asserted) - vendor/dormouse-fused/crates/burn-gdn2/tests/fused_adjoint_vs_ops.rs d in-crate chunk_wy_forward per-op autograd, on bare tensors the fused CUDA ADJOINT, on two shapes chosen to localise a wrong term the fused forward; the state OUTPUT (a leaf on both paths, so d_s there is the INPUT state’s gradient) vendor/dormouse-fused/crates/burn-gdn2/tests/fused_chunk_verify.rs d in-crate chunk_wy_forward the fused CUDA chunk forward; zero-key-row gradient finiteness its own fused_op_grads_match_tensor_path_cuda, which compared the TENSOR adjoint to the tensor path (see that file’s header) vendor/dormouse-fused/crates/burn-gdn2/tests/fused_launch_count.rs d two hand-written CUDA kernels in the SAME file (spec-flashkda.md §1: fwd_kernel1.cuh + fwd_kernel2.cuh) the launch COUNT of the module path vs the scratch path, i.e. that a call that grew an extra kernel is visible; nothing numeric any correctness claim - this is a counter, and a count cannot see a wrong answer registered (d) and not (b): the two kernels it compares against are in this file, so arm-vs-arm is the whole comparison. Requires cuda,autodiff and does not run in the default cell. vendor/dormouse-fused/crates/burn-gdn2/tests/fused_permuted_view.rs d in-crate, strided vs contiguous views the seam on NON-CONTIGUOUS input (the stack overflow); contiguity left alone the numerics of the recurrence vendor/dormouse-fused/crates/burn-gdn2/tests/lowp_bf16_cuda.rs b IEEE-754 round-to-nearest-even, via the third-party half crate - the one reference in the tree that is neither our code nor our transcription bf16 STORAGE as u16 bit patterns + f32 accumulation; the f32-only dtype gate the recurrence; anything else ‘bit-exact’ is CORRECT here and the one legitimate use of the word outside tier (a): the expected value is half::bf16::from_f32, a third-party implementation of IEEE-754, not another arm and not our transcription. Registered (b) not (a) because the half crate is not the mechanism’s authors’ code, so ADR-0020’s AUTHORS label would be a different kind of false claim. vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_autodiff.rs d central finite differences of the plain path + cross-arm RAGGED tail (T not divisible by chunk) in the custom node’s backward; both arms project/output; the fused kernel vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_bench_cuda.rs x none (nothing asserted) - vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_diff.rs d in-crate chunk_wy_forward_loop (the untouched production arm) CHUNK: the finite-Neumann rewrite, 9 cases incl. a hostile one and a ragged tail; TILE routing past 32 project/output; the fused kernel; gradients vendor/dormouse-fused/crates/burn-gdn2/tests/ops_batched_grad_cuda.rs d central finite differences of the same forward on Autodiff<CudaBare, BalancedCheckpointing> GRAD for BOTH arms on the trainer’s backend; 8 coordinates/tensor at a 5% rel bar project/output; the fused kernel vendor/dormouse-fused/crates/burn-gdn2/tests/official_forward.rs b arXiv:2605.22791 Eq 9/10/11/12 and §3.5, re-derived in f64 per token in THIS file - a transcription, and a no-fixture one, so it is runnable rather than committed PAPER-SEMANTICS across 10 configs x 2 entry points; its own short conv, its own head-major layout, its own reduction order (it shares no code with the chunked path); TOL = 1e-5, measured 5.04e-09 the authors’ own Triton kernel (never run); the 4-D/strided stages the example dumps the f64 layer (ref_f64.rs) is the fixture-based sibling of this one; the two disagree in TIER, not in verdict - this file has no committed bytes, so a reader can run it, and ref_f64.rs is the one CI can diff. docs/papers/gdn-kda.md carries the arXiv id because the file cites the equations through that report rather than the paper directly. vendor/dormouse-fused/crates/burn-gdn2/tests/ref_f64.rs b tests/ref_f64.bin, emitted by tools/gen_reference_f64.py, itself an f64 transcription of arXiv:2605.22791 Eq 9-12 with the three non-paper lines (the 1/sqrt(K) scale, the short conv’s ZERO left pad, the L2-norm eps inside the sqrt) each citing the file it came from PAPER-SEMANTICS; project; short_conv_1d; output; the STATE carry; both dispatch arms; 18 cases T=1..70 the authors’ own Triton kernel (never run - ORACLE.md §8 candidate (2), not attempted). A shared MISREADING of the paper survives a transcription, which is why this is (b) and not (a) RED until 2026-09-29 and the cause was THIS LAYER, not the kernel: the generator reshaped g head-major while q/k/b/v used the token-major idiom, and the two coincide at T=1 only, so case 0 passed and case 1 read 9.227e-02. The whole episode is in the file’s STATUS block. It is a second instance of the ff7cd57 generator-layout defect, in a file written after that fix. vendor/dormouse-fused/crates/burn-gdn2/tests/common/ref_f64.rs b the same ref_f64.bin + tools/gen_reference_f64.py as ref_f64.rs; it is the shared reader, not a test of its own (a leading-underscore-free file in tests/ would be) the FIXTURE FORMAT: magic, header, and the ‘no trailing bytes’ assertion. Asserts nothing about any number everything numeric - it contains no comparison at all, only the loader and the module builder the two callers share registered as a file because R1 scans tests/ mechanically and an include!d helper is not a test target. Waiving it would leave the loader undeclared, and the loader is where a silent format change would land. vendor/dormouse-fused/crates/burn-gdn2/examples/ref_f64_stages.rs b the same f64 transcription as ref_f64.rs, but per-STAGE: tools/gen_reference_f64.py --diff-stages reads this example’s dump and compares each stage separately the DIAGNOSTIC, not a verdict: it names the FIRST stage of project that disagrees with the f64 transcription, which is how the 2026-09-29 g-reshape defect was localised in minutes rather than by bisecting the layer the 4-D permuted stages, which it does NOT compare: this backend’s into_data() on a strided view does not read in a stable order, so a 4-D row would be a false positive (see the example’s header) it is an example, not a test: cargo test never runs it, so it can never be the thing that keeps a regression out. It is the instrument, and the gate that uses it is the one in the tier (b) sibling. vendor/dormouse-fused/crates/burn-gdn2/src/lib.rs c tests/ref_data.bin (our transcription, same as bit_exact.rs) a feature list its binary-tests bullet said ‘bit-exact reference tests’, which is a tier-(a) claim about a tier-(c) fixture. ADR-0020 listed the same defect in the README; the doc comment was missed and is fixed in this lane vendor/dormouse-fused/crates/burn-kda/src/lib.rs d n/a - no fidelity claim in the file (documents the Kimi Linear / K3 equations, which is provenance, not a comparison) any numeric claim: no test in this crate compares against either paper vendor/dormouse-fused/crates/burn-gdn2/src/lib.rs b the f64 fixture layer (same as oracle_breadth.rs) a feature list its binary-tests bullet used to say “bit-exact reference tests” about a tier-(c) f32 fixture; rewritten 2026-09-29 to name the f64 transcription, the 1e-3 relative bar, and that it is neither bit-for-bit nor tier (a) the bullet names the tier-(a) vocabulary ONLY to disclaim it (ADR-0020 R2 fires on the phrase, not on the claim): ‘Not bit-for-bit, and not tier (a)’ vendor/dormouse-fused/crates/burn-gdn2/tests/oracle_breadth.rs b tests/ref_f64_broad.bin, emitted by tools/gen_reference_f64.py: an f64 transcription of arXiv:2605.22791 3.1 Eq. 8-12 (tools/gen_reference_f64.py), with the three details not in the paper each cited to the authors’ own source: lit_gpt/gdn2_ops/chunk_gdn2.py for the K**-0.5 scale on the whole readout, fla/modules/conv/triton/kernels.py for the ZERO pad, fla/modules/l2norm.py for eps inside the sqrt PAPER-SEMANTICS; project (layout, L2 norm, decay parameterisation, GVA repeat); short_conv_1d; output (gate, o_norm, o_proj); the STATE carry. 1000 cases at T in 1..=38 - the T sweep of the fixture it replaced, so the breadth is preserved and only the oracle changed the fused CUDA kernel, and the chunked arm (that is oracle_chunk.rs). RED on a pre-existing state-carry defect: measured worst 8.9402e-01 relative, 976/1000 cases over the 1e-3 bar; every stage of project clean to <= 5.2e-07 including all seven per-head 4-D tensors, and token 0 correct at every length the header names the tier-(a) vocabulary ONLY to disclaim it (ADR-0020 R2 fires on the phrase, not on the claim). See the STATUS block for the measured tier-(b) wording vendor/dormouse-fused/crates/burn-gdn2/tests/oracle_chunk.rs b tests/ref_f64_broad.bin (the same f64 transcription as oracle_breadth.rs) PAPER-SEMANTICS at chunk sizes 4/8/16/32/64 over the same 1000 cases, plus chunk-vs-fused under REAL per-channel decay at T=130 the fused CUDA kernel. Its own arithmetic: the chunked arm re-orders a DIFFERENT factorisation (the chunked WY solve), not the same loop, so it needed its own arm - and measured, the pre-existing defect swamps it (identical 8.9402e-01 worst at all five sizes) the header names the tier-(a) vocabulary ONLY to disclaim it (ADR-0020 R2 fires on the phrase, not on the claim). See the STATUS block for the measured tier-(b) wording vendor/dormouse-fused/crates/burn-gdn2/tests/ref_f64.rs b tests/ref_f64.bin (18 cases) and tests/ref_f64_faults.bin (the seven wrong formulas): an f64 transcription of arXiv:2605.22791 3.1 Eq. 8-12 (tools/gen_reference_f64.py), with the three details not in the paper each cited to the authors’ own source: lit_gpt/gdn2_ops/chunk_gdn2.py for the K**-0.5 scale on the whole readout, fla/modules/conv/triton/kernels.py for the ZERO pad, fla/modules/l2norm.py for eps inside the sqrt PAPER-SEMANTICS on both dispatch arms at T=1..70, plus the NEGATIVE CONTROL: the_bar_bites_a_wrong_formula asserts on every run that our output is at least 1e-1 relative from each of the seven, so the bar cannot rot into a self-consistency check the fused CUDA kernel. RED on the same pre-existing state-carry defect (9.227e-02 at T=2, measured on base dbfa4ca before this retarget); its STATUS block records the localisation and the one measurement that could not be reproduced the header names the tier-(a) vocabulary ONLY to disclaim it (ADR-0020 R2 fires on the phrase, not on the claim). See the STATUS block for the measured tier-(b) wording vendor/dormouse-fused/crates/burn-gdn2/tests/common/ref_f64.rs b the loader for both f64 fixtures, and build() for the module under test nothing on its own: it is include!d by ref_f64.rs, oracle_breadth.rs, oracle_chunk.rs and the ref_f64_stages example. It is not a test target everything, since it is where a fixture-layout or builder error would enter all four vendor/dormouse-fused/crates/burn-gdn2/examples/ref_f64_stages.rs b reads the f64 stages out of project and the generator diffs them one at a time (--diff-stages) a STAGE against an outside reference rather than two arms against each other, which is the only way to see inside project. It is what localised this crate live defect to the state carry, and what confirmed the 0a6998a conv-pad fix (3.0e+00 -> 1.7e-07) the recurrence and output - it stops at the end of project by construction. A TOOL, not a gate: it has no assertions vendor/dormouse-fused/crates/burn-gdn2/tests/official_forward.rs b an f64 per-token transcription of Eq 9/10/11/12 written from the papers, with NO fixture the forward as the equations state it, 10 shapes x 2 entry points, on NdArray. It predates the f64 fixture layer and is the tier-1 answer to the same question the CUDA kernels (it runs on NdArray, so it covers the tensor paths only) vendor/dormouse-fused/crates/burn-rmsnorm/tests/rmsnorm_oracle.rs a RAN, not transcribed: torch.nn.functional.rms_norm (torch==2.14.0+cpu, pytorch/pytorch v2.14.0, ATen torch::rms_norm) and fla.modules.layernorm.rms_norm_ref (flash-linear-attention==0.5.2, fla-org/flash-linear-attention, sha256(fla/modules/layernorm.py)=e78b729b..c6d6f), both EXECUTED 2026-09-29 on CPU and emitted to tests/fixtures/rmsnorm_oracle.txt at 9 significant digits. Both are byte-pinned as transcripts under tests/oracle/upstream/, so the gate needs no network. The two upstreams agree with each other to 0.0 relative on all 12 cases (identical f32), so the expected column is not a compromise between two opinions. Regeneration command: tests/oracle/gen_rmsnorm_oracle.py the eps INSIDE-vs-OUTSIDE-vs-DROPPED question (the decisive cases sit at rms 5e-5..2e-3, where the gaps are O(0.1..1); the worst is 44538x the tolerance); the LayerNorm-style centring misreading (1962x); the reduction axis (122173x on a square cube); eps as a parameter of the call, checked by running the kernel at eps=1e-5 and eps=0 on ONE tensor; the per-feature gain broadcast (non-constant gains on 11 of 12 cases) the fused CUDA kernel, which this file’s arithmetic never touches - it is covered separately, and correctly so, by tests/rmsnorm_kernel_cuda.rs (it DOES run on a bare device, and the trainer never has one); WHETHER either upstream faithfully transcribes arXiv:1910.07467, whose AUTHORS SHIP NO CODE, so tier (a) here means ‘the two public reference implementations of the mechanism’, not ‘the authors of the paper’. A shared misreading of Zhang & Sennrich survives this test. The bf16 and f64 paths vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/gen_rmsnorm_oracle.py a the same two upstreams it runs (torch 2.14.0+cpu, flash-linear-attention 0.5.2). It is the GENERATOR, and it REFUSES to write a fixture on which the upstreams disagree by more than 1e-6, or on which any of the crate’s own guards would be unsatisfiable is the fixture’s provenance: the sha256 of the fla file it read, the torch tag, and the 9-significant-digit encoding that round-trips f32 anything about the Rust tree - it writes no Rust vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/mutate_kernel.sh x n/a - it runs the crate’s own tests against deliberately wrong kernels that the oracle CAN FAIL: five mutants of RMSNorm::forward’s tensor path (eps outside the sqrt / dropped / hardcoded, gain collapsed to its mean, reduction over dim 1), each of which turns at least one test red. It asserts nothing about the numerics itself - vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/upstream/torch_rms_norm.py a verbatim inspect.getsource() of the two PyTorch entry points that were executed, from torch 2.14.0+cpu (pytorch/pytorch v2.14.0). TRANSCRIPT of upstream source, re-extractable with gen_rmsnorm_oracle.py --dump which upstream code was run, so the version in the fixture header is not an unbacked claim the arithmetic: it dispatches to COMPILED C++ (aten/src/ATen/native/layer_norm.cpp::rms_norm), which is not quotable here and is not pinned by this file vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/upstream/fla_rms_norm_ref.py a verbatim inspect.getsource() of fla.modules.layernorm.rms_norm_ref from flash-linear-attention 0.5.2 (fla-org/flash-linear-attention), the file whose sha256 (e78b729b..c6d6f) is in the fixture header. TRANSCRIPT, re-extractable with --dump which upstream code was run any revision handle: the wheel carries NO git revision, so the sha256 is the only one available and this fixture is tied to that hash rather than to a commit vendor/dormouse-fused/crates/burn-rmsnorm/tests/fixtures/rmsnorm_oracle.txt a GENERATED by tests/oracle/gen_rmsnorm_oracle.py from the two upstreams above; 9 significant digits of the f32 they produced. Do not hand-edit - a hand-edited golden is exactly what tier (a) exists to replace carries the right answers AND the four WRONG formulas as separate columns, so every margin in rmsnorm_oracle.rs is measured rather than assumed - vendor/dormouse-fused/crates/burn-rmsnorm/src/lib.rs d in-file scalar f64 loop over host memory in forward_matches_scalar_reference (an independent formulation, not the tensor chain restated) the tensor path against a host-side loop on 3x4x8 with a non-constant gain the fused CUDA arm (the scalar loop is the CPU path’s oracle only); the tolerance there (1e-4 relative) is ~1000x looser than the tier-(a) test’s 1e-5, which is the reason the tier-(a) test exists vendor/dormouse-fused/crates/burn-rmsnorm/tests/rmsnorm_kernel_cuda.rs a the SAME two upstreams the tensor path is compared against, via the SAME generated fixture tests/fixtures/rmsnorm_oracle.txt (torch.nn.functional.rms_norm -> torch.rms_norm, ATen torch::rms_norm, torch==2.14.0+cpu, pytorch/pytorch v2.14.0; and fla.modules.layernorm.rms_norm_ref, flash-linear-attention==0.5.2, fla-org/flash-linear-attention, sha256(fla/modules/layernorm.py)=e78b729b..c6d6f) - here measured against the FUSED CUDA KERNEL’s own output (src/fused.rs), on a bare (non-autodiff) Device::cuda(0), which is the one shape on which it runs at all the kernel’s own arithmetic on all 12 fixture cases at the sibling’s TOL_REL 1e-5, unloosened: eps inside the sqrt, the per-feature gain index, the /d of the reduction, and the strided tail at d=1/2/13. PLUS REACHABILITY, which is the part no other file owns: the seam counters (asked and ran) are pinned around every single case, so a silent decline to the tensor path fails the test instead of re-testing the tensor path under a file whose name says otherwise; and the trainer’s autodiff shape and its valid() eval snapshot are gates on the norm=0/N claim the trainer’s exact cubecl runtime: this target compiles in the burn-fused workspace, where the root [patch.crates-io] does not apply, so the kernel runs on the registry cubecl 0.11.0-pre.4 while the trainer runs the vendored fork; the BACKWARD (fused.rs returns a fresh plain Tensor::empty, so were it ever reached from an autodiff input the arm would carry no gradient - the burn_gdn2 defect, and the reason the refusal is the thing to preserve); the bf16/f16 arms, which fused.rs declines by dtype; WHETHER either upstream faithfully transcribes arXiv:1910.07467, whose AUTHORS SHIP NO CODE - vendor/dormouse-fused/crates/burn-rmsnorm/tests/oracle/mutate_fused_kernel.sh x n/a - it runs the crate’s own CUDA tests against deliberately wrong fused kernels that the KERNEL-path oracle can fail: five mutants of src/fused.rs (eps outside the sqrt / dropped / hardcoded to 1.1920929e-7, the per-feature gain collapsed to w[0], the reduction’s /d dropped), each of which turns at least one test red. It snapshots and restores the source, traps on every exit path and md5-compares at the end - - vendor/dormouse-fused/crates/burn-rmsnorm/tests/fused_kernel_gate.rs a a scalar f64 definition of x / sqrt(mean(x^2) + eps) * gain written out in the file (NOT a transcription of the crate, and NOT the tier-(a) torch/fla fixture); a CONTROL through this crate on ndarray against the same f64 reference so a pass cannot come from the reference agreeing with itself that the fused CUDA arm is TAKEN, read from the seam counter rather than assumed, and that its answer matches f64 to 1e-5 relative at mean-squares spanning 1e-4..1e2 (measured worst 1.168e-7 over 84 outputs, asked 6 skipped 0, 2026-09-30) so the eps question is decided; that the backward-less arm DECLINES on an autodiff device (the norm=0/N of the trainer logs, as a gate); and that d<4 DECLINES and its fallback is correct the BACKWARD (rmsnorm_cuda returns a fresh Tensor::empty with raw handles in, so were it reached from an autodiff input the arm would carry no gradient - the burn_gdn2 failure mode, and the reason the dispatch refusal is the thing to preserve); d in {1,2,3} (REFUSED - the launch does not execute its trailing cubes there, see tests/d2_isolate.rs, and MIN_FUSED_D=4 is a measured envelope not a derived one); the torch/fla columns, which rmsnorm_kernel_cuda.rs owns; the trainer’s cubecl runtime (this target compiles in the burn-fused workspace, where the root [patch.crates-io] does not apply, so the kernel runs on the registry cubecl 0.11.0-pre.4) - vendor/dormouse-fused/crates/burn-rmsnorm/tests/lower_probe.rs x n/a - it compares no value against any reference. Its rungs assert only that a kernel LOWERED and wrote the value the rung itself predicts, which is what separates “failed to compile” from “computed something else” WHICH PART of the kernel fails to lower, one rung at a time. This is the bisect that retired the 34c5631/9ac0377 diagnosis: p2 (shared alloc, comptime size, one write, one barrier, one read) LOWERS, p4 (a sync_cube inside a runtime-bounded while, no shared at all) LOWERS, p6 (the same kernel, reduction serialised) LOWERS at 1.72e-7, p9 (the halving while with NO barrier anywhere) FAILS, p5/p7 (the halving while) FAIL, p10 (the same reduction as for k in 0..log_threads over a comptime trip count) LOWERS at 1.72e-7 the kernel’s NUMERICS - it is a lowering instrument, not a correctness one, and its per-rung tolerance is 1e-4 on purpose; p5/p7/p9 are #[ignore]d reproducers that FAIL on purpose, and each rung must be run in its own process (--exact <rung>) because a launch failure poisons the CUDA context for the rest of the binary - vendor/dormouse-fused/crates/burn-rmsnorm/tests/d2_isolate.rs x n/a - it compares no value against any reference. It is an EXCLUSION table: the point is to prove which suspects are NOT the cause by making them reproduce or not reproduce that the SECOND defect is not the kernel body, not the grid, not a runtime grid count, not the block size and not a readback race, but the OUTPUT TENSOR’S SHAPE. Same 4-line kernel (out[CUBE_POS_X] = 1.0, no shared memory, no barrier), same 4-cube grid, same 16-element length: out [8,2] runs 2 cubes and [16,1] runs 4, [1,1] runs 1, [2,1] runs 2, [3,1] runs 3, while [1,16]/[2,8]/[4,4]/[4,1]/[5,1] run 4. CubeDim 32..1024 truncate identically; four reads agree and an explicit client.sync() changes nothing the RULE behind that shape dependence. It lives inside cubecl’s launch path and is NOT isolated; 12 shape samples did not yield it and it is not guessed at. MIN_FUSED_D = 4 in src/fused.rs is the measured envelope, not a law, and the mechanism is an open follow-up rather than a closed question - vendor/dormouse-fused/crates/burn-gdn2/tests/fused_launch_count.rs x n/a - it counts CUDA launches per forward via alloc_trace::fused_launches_per_call(), it compares no value to any reference the claim that the module path issues 2 kernels and the scratch path 3, which a CALL counter cannot see (fused_chunk_forward used to route through …_scratch and discard the scratch) CUDA only, so tools/lib_gate.sh does not run it; the vendor GPU gate does - vendor/dormouse-fused/crates/burn-gdn2/tests/autodiff_bwd_f64.rs b f64 forward-mode AD + full-tensor central differences over a TRANSCRIPTION of chunk_wy_forward_batched (tools/gen_bwd_f64.py, tools/fwd_mode.py), committed as tests/ref_bwd_f64.bin the analytic adjoint (custom node, f32) on ALL 1792 coordinates of all seven inputs; the FORWARD against the f64 transcription first, which is what bounds the transcription risk; the bar’s far side from 10 wrong formulas in ref_bwd_f64_faults.bin, three of which this shape provably cannot exercise and are named a shared MISREADING of the specification, which survives any transcription; the fused CUDA kernel (CPU build); the inter-chunk half of the adjoint (one chunk, so no BK2 and no d_k_bptt/d_e_bptt/d_s_shift); any two-chunk shape, where the forward disagrees with the transcription at 8.3e-1 TIER (b) NOT (a): the two methods are independent of each other, so the DERIVATIVE is not a transcription, but the FORWARD is. The words bit-exact/bit-for-bit are not used about it. vendor/dormouse-fused/crates/burn-gdn2/tests/fused_adjoint_f64.rs b tests/ref_bwd_f64.bin - forward-mode AD in f64 over a transcription of the forward, cross-checked inside the generator against full-tensor central finite differences (the two agree to 1.2e-12) a wrong adjoint, a MISSING GRADIENT, a dropped term, a transposed contraction, a sign error, and a gradient of a different function - none of which any arm-vs-arm comparison can see, because both sides of those are our own forward differentiated by the same framework and a misreading cancels. Demonstrated red: negating one term’s expected gradient turns it red. The forward is pinned separately at 1.4e-7 by tests/autodiff_bwd_f64.rs CUDA only (required-features = [cuda, autodiff]), so tools/lib_gate.sh does not run it; the vendor GPU gate does. It is the first measurement in this project that any fused-adjoint kernel has been compared to anything at all - fused_chunk_verify.rs compared the tensor adjoint against the tensor path - vendor/dormouse-fused/crates/burn-engram/src/hasher.rs b a port of NgramHashMapping._get_ngram_hashes from deepseek-ai/Engram (arXiv:2601.07372), the official reference reclassified 2026-09-30 from (d): my bulk pass went by ‘no oracle keyword’ and missed the module doc’s ‘Port of … from the official reference’. A hand port of named upstream code is a TRANSCRIPTION, which is tier (b) - not the same as comparing our code to itself - - vendor/dormouse-fused/crates/burn-engram/tests/engram_oracle.rs a RAN, not transcribed: deepseek-ai/Engram@main engram_demo_v1.py (EngramModule.forward), executed on CPU 2026-09-29 and vendored under tests/oracle/ so the gate needs no network reclassified 2026-09-30 from (b): the bulk declaration went by filename and this is a TEST that RUNS the official code, not a transcription. The gate agrees to 1e-5 on the gate, 2e-5 on the module forward, 1e-5 on the conv, EXACTLY on the prime ladder, and the_claim proves the tolerance is not wider than the fixture’s discriminating power. This is the oldest tier-(a) row in the tree - it predates the doctrine, and it sat unregistered for a month while red - - vendor/dormouse-fused/crates/burn-engram/tests/oracle/engram_demo_v1.py a the upstream code this generator RUNS; versions/sha are in the fixture header DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong) - - vendor/dormouse-fused/crates/burn-engram/tests/oracle/gen_engram_oracle.py a the upstream code this generator RUNS; versions/sha are in the fixture header DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong) - - vendor/dormouse-fused/crates/burn-muon-plus/tests/bf16_matmul.rs x none - it CHARACTERISES what bf16 does on this backend (measured), rather than checking a value against any reference reclassified 2026-09-30 from (d): a characterisation is not a self-comparison, and filing it (d) would let a reader count it as evidence of fidelity. What it IS worth is in the file - - vendor/dormouse-fused/crates/burn-muon-plus/tests/self_checks.rs d in-crate: an independent formulation or a counter, NOT an external reference DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong) - - vendor/dormouse-fused/crates/burn-muon-plus/tests/zero_grad.rs d in-crate: an independent formulation or a counter, NOT an external reference DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong) - - vendor/dormouse-fused/crates/burn-sct/examples/bench_gpu.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-sct/examples/bench_ops.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-sct/examples/gpu_check.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-sct/examples/gpu_mm.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-sct/examples/gpu_svd.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-sct/examples/gpu_svd2.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-sct/examples/mm_probe.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-sct/tests/cuda_retract.rs d in-crate: an independent formulation or a counter, NOT an external reference DECLARED 2026-09-30 in bulk, then individually reviewed 2026-09-30 (all 24 bulk rows were re-read by hand; 7 were reclassified, 3 of those because the bulk pass was wrong) - - vendor/dormouse-fused/crates/burn-spectral/examples/gpu_check.rs d in-crate: a CUDA availability/shape check, asserted rather than timed reclassified 2026-09-30 from (x): 2 asserts. Named like a probe, used like a test - - vendor/dormouse-fused/crates/burn-spectral/examples/infer_bench.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-spectral/examples/linear_timing.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-spectral/examples/moe_flops.rs d in-crate: MoE FLOP accounting against the same accounting computed another way reclassified 2026-09-30 from (x): carries an assert, so it asserts something. 1 assert is few but not none - - vendor/dormouse-fused/crates/burn-spectral/examples/moe_timing.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-spectral/examples/moe_timing2.rs x none - a benchmark or a manual probe; it asserts no value against any reference reclassified 2026-09-30 from (d): a timing or a shape probe is not a correctness test, and calling it (d) would put it in the same column as a real self-comparison - - vendor/dormouse-fused/crates/burn-spectral/examples/tsct_diag.rs d in-crate: does TSCT actually learn - a mini-GPT on a char-level task, dense vs SpectralLinear vs SpectralMoE at a matched parameter budget reclassified 2026-09-30 from (x): a diagnostic that answers ‘does this mechanism learn’ is a self-comparison, which is exactly tier (d). 14 asserts - - vendor/dormouse-fused/crates/burn-spectral/src/lib.rs b arXiv:2602.21545v3 Appendix D.3, which prints the PolarExpress schedule ending at exactly (1.875, -1.25, 0.375); v1 and v2 print no NS coefficients at all reclassified 2026-09-30 from (d): the coefficients are hand-verified against a named appendix of a pinned version, which is a transcription of a primary source. NOT tier (a): no upstream code was executed - - vendor/dormouse-fused/crates/burn-spectral/src/moe_fused.rs d in-crate: the fused token-choice MoE forward+backward against the same maths in tensor ops, and assert-based self-checks reclassified 2026-09-30 from (x) a SECOND time: I filed it as an example/benchmark by PATH, and it is a SOURCE FILE - the fused CUDA MoE kernel - carrying 49 asserts. Assert count is the honest discriminator, not the path - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/README.md x none - provenance and re-run instructions for the oracle directory above - - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/final_numbers.py a a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/illconditioned_sweep.py a a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/measure_algorithms.py a a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/pin_findings.py a a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/run_polar_express.py a a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/run_targets_2_and_3.py a a SCRIPT that RUNS the upstream references and emits the transcripts - it is the provenance of the tier-(a) rows above, and keeping it is what makes them reproducible offline DECLARED 2026-09-30 alongside the spectral oracle; the documents and transcripts in this tree are the first tier-(a) evidence for burn-spectral - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/gram_newton_schulz_README.md a VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/kellerjordan_muon_post.html a VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/kellerjordan_newtonschulz5.py a VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/novelai_polarexpress.py a VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/novelai_polarexpress3.py a VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/polar_express.py a VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/polar_express_LICENSE a VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/upstream/polar_express_README.md a VERBATIM transcript of upstream source that was executed 2026-09-30; do not hand-edit that the pinned source is what actually ran, and that it is unmodified - a transcript is what makes the (a) claim checkable offline rather than a promise - - vendor/dormouse-fused/crates/burn-spectral/tests/oracle/audit_2026_10_01.py b TRANSCRIPTION of vendor/dormouse-fused/crates/burn-spectral/src/lib.rs:208-341 (the retraction, the power iteration, the Stiefel metric) re-expressed in torch; a REFERENCE only where it says LAPACK. Wheel pinned: torch 2.14.0+cpu, numpy 2.5.2, python 3.12.14, CPU, f64 unless a line says f32. The coefficients own provenance is arXiv:2602.21545v3 Appendix D.3, as cited in lib.rs that the transcription reproduces the claims the Rust COMMENTS make: p(1)=1 and p’(1)=0, the basin edge sqrt(7/3)=1.5275, the Rayleigh estimate error as a function of how flat the spectrum is, and the retracted Gram is I. Findings 1-3 of docs/reviews/spectral-audit-2026-10-01.md were produced by it anything about the Rust itself - it is a transcription, not the code; f32 (it is f64); CUDA; the REACHABILITY of the class-B-2 hole, which is sec4_fixed.py and sec4c_tolerance.py R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column. vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec4_fixed.py b the same transcription restricted to one question: can the sigma_max estimate put the NS input OUTSIDE the basin? M is built as the Cholesky factor of a KNOWN Gram (M M^T = G, asserted in the script, not assumed) so lambda_1 is exact and no eigenbasis search is involved that the class-B-2 hole is LATENT and not live: 0 of 4000 random Wishart draws and 0 of the adversarial-drift rows land outside the basin, worst prescaled sigma_max 1.1549 against an edge of 1.5275 the diverging case itself (that is sec4c_tolerance.py); f32; CUDA; anything about the Rust R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column. vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec4c_tolerance.py b the same transcription with the spectrum built IN CLOSED FORM (G = lam_restI + (1-lam_rest) u1u1^T + (l2-lam_rest) u2u2^T, top eigenvector at a controlled overlap delta with the all-ones direction), so l2/l1 is known rather than searched that at l2/l1 = 0.5/0.3/0.1/0.01 with delta = 1e-9 the 3-iteration retraction returns f64 max|out| ~ 3.3e+60 and inf in f32 (f32 max is 3.4028e+38) - the ‘inf in the trainer dtype’ of class B-2; and that a Frobenius prescale cannot diverge on the same factors (it lands at 0.95 and 0.61) reachability (that is sec4_fixed.py); f64 for anything but the overflow, which is where f32 differs; CUDA; anything about the Rust R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column. vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec4d_guard.py b the same transcription plus the ONE-LINE GUARD it was written to price: sigma_used = max(sigma_est, ||X||_F / (1.05sqrt(7/3))), which Cauchy-Schwarz makes provably in-basin for every input that the guard is WRONG as a fix, which is what the B-2 gate records: it engaged on 21 of 21 cases INCLUDING all four well-behaved [64,4] Gaussians and the orthonormal [768,64] (sigma_max = 1 exactly, ||X||_F = 8, so ||X||_F/1.604 = 4.99 beats a correct estimate of 1). It converges - to the wrong place, silently the sigma_max consequence (the printed columns are entry magnitudes, not sigma_max; that number is docs/papers/spectral-reference.md 3.4); CUDA; anything about the Rust R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column. vendor/dormouse-fused/crates/burn-spectral/tests/oracle/sec5_6b.py b the transcription AND LAPACK: torch.linalg.polar on the same factor, i.e. the DEFINITION of a polar factor rather than another arm of ours. LAPACK is a third-party implementation of the definition, not the mechanism’s authors class B-1: the per-entry ||U^T U - I|| of a 3-ITERATION retraction against the trainer’s one-way 1e-3 latch, at spectral spreads 0.3/0.1/0.01 = 8.3e-4 / 3.3e-2 / 8.5e-2, i.e. 0.8x / 32.6x / 85.0x the latch; and that 5 iterations survives a 10:1 spread. Also the section-5 fix: the first version measured svdvals on a WIDE matrix and read a rank deficiency as a result whether any run on record ever reaches those spreads - NO run has been instrumented for the factor’s spectrum, which is the reason this is class B and not a defect; CUDA; the batched arm R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column. vendor/dormouse-fused/crates/burn-spectral/tests/oracle/gate_dryrun.py b a numpy dry-run of the FOUR gates this audit landed, at the Rust’s own dtype (f32), written before the cargo slot because a cold build of vendor/dormouse-fused costs ~20 min of queue that the gates’ LOGIC is right before they reach cargo. It found all three fixture defects section 11.1 of the audit records: the Gram passed where the code estimates on a FACTOR (so the estimate came back correct over the finding), a ‘basis’ that was 548:1 degenerate before any spread, and a log-spaced fixture that could not have refuted the comment the Rust itself - no compile error and no wrong dtype is visible here; the production CANONICAL TRANSPOSE (lib.rs:211-215), which it had to be taught or it forms the [768,768] Gram and reproduces by accident exactly the Frobenius-prescale failure this audit disproves R3 wants an arXiv id or a named fixture+generator for tier (b), and neither form fits: the reference is LAPACK (torch.linalg.polar), a third-party implementation of the DEFINITION, not the mechanism authors’ code. The coefficients own paper id is in the target column. vendor/dormouse-fused/crates/burn-spectral/tests/oracle/falsify.sh x none - it runs the crate’s own tests against deliberately perturbed code and asserts nothing about an external reference that each gate turns RED on the mutation it exists to catch, on its OWN assertion and not merely on a non-zero exit, and that the restore is byte-identical by sha256. It is the evidence that the gates are gates anything about the algorithm: an EQUIVALENT mutation cannot fail, and section B’s first version was exactly that (both arms of a bit-identity perturbed together, which stays identical by construction) - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/optim/muon_plus.py a RAN, not transcribed: K1seki221/MuonPlus @ 8a9ace123afedaab8ba75ea0b19315594ae1da7c (last push 2026-02-26) - the Muon+ AUTHORS’ own implementation, named in their paper’s abstract. Pinned and sha256-checked by gen_oracle.py, which REFUSES to write a fixture if the pin is rotated the NS coefficients and the polar operator against the authors’ code rather than against a reading of the paper; also adjust_lr_for_muon (muon_plus.py:245-252), which FALSIFIED a comment in our own lib.rs:456-479 - it says the max(1,·) follows the Muon+ implementation, and the implementation has no max - - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/optim/polar_express.py a RAN: the PolarExpress authors’ own generator, from NoahAmsel/PolarExpress @ 71cc379 that App. D.3’s printed schedule is NOT reproducible from the authors’ repository (~6e-3 from entry 1) - a finding about the paper, not about us - - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/muon_oracle.bin a the f32 the authors’ code produced, at 9 significant digits; gen_oracle.py regenerates it byte-identically a wrong coefficient, a wrong composition order, and a transposed normalisation axis - all demonstrated red by tests/oracle/falsify.sh - - vendor/dormouse-fused/crates/burn-muon-plus/tests/muon_oracle.rs a the four artifacts above; NO feature gate and no Python at test time, because the expected values are committed bytes a wrong NS coefficient (last digit), a wrong ColRow composition order (2.54e-1 on the col_row cases), and a transposed norm_col axis (O(1)). One mutation is EXPECTED TO STAY GREEN - the eps floor - and the test says why, because that is a property of the FIXTURE and stating it is more useful than a red line nobody can act on - - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/falsify.sh x none - it runs the crate’s own tests against deliberately perturbed code, and asserts nothing itself that the oracle CAN fail: five perturbations, each reverted, with the tree restored byte-identical - - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/PROVENANCE.md x repo/commit/date/sha256 table for the pinned upstream - - - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/gen_oracle.py a a SCRIPT that RUNS the pinned upstream and emits muon_oracle.bin; it refuses to write if the upstream sha256 is rotated, so a silent upstream change cannot produce a new green the provenance of the (a) rows above: the pin check is itself demonstrated red by falsify.sh, which mutates the file and gets ‘PIN ROTATED’ with both hashes named - - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/measure_ns_snr.py a a SCRIPT that RUNS the pinned upstream and emits muon_oracle.bin; it refuses to write if the upstream sha256 is rotated, so a silent upstream change cannot produce a new green the provenance of the (a) rows above: the pin check is itself demonstrated red by falsify.sh, which mutates the file and gets ‘PIN ROTATED’ with both hashes named - - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/transcript.txt x captured output of the scripts beside it; evidence, not a test - - - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/init.py a a SCRIPT that RUNS the pinned upstream and emits muon_oracle.bin; it refuses to write if the upstream sha256 is rotated, so a silent upstream change cannot produce a new green the provenance of the (a) rows above: the pin check is itself demonstrated red by falsify.sh, which mutates the file and gets ‘PIN ROTATED’ with both hashes named - - vendor/dormouse-fused/crates/burn-muon-plus/tests/oracle/upstream/utils/optim/init.py a a SCRIPT that RUNS the pinned upstream and emits muon_oracle.bin; it refuses to write if the upstream sha256 is rotated, so a silent upstream change cannot produce a new green the provenance of the (a) rows above: the pin check is itself demonstrated red by falsify.sh, which mutates the file and gets ‘PIN ROTATED’ with both hashes named - - vendor/dormouse-fused/crates/burn-kda/tests/kda_oracle.rs a RAN, not transcribed: fla-org/flash-linear-attention@9f38d24980c46d46bd38614e743cdacd21906578, fla/ops/kda/gate.py::naive_kda_gate + naive_kda_lowerbound_gate and fla/ops/kda/naive.py::naive_recurrent_kda + naive_chunk_kda, executed on CPU 2026-09-30 (torch 2.14.0+cpu, einops 0.8.2). FLA’s own pure-PyTorch references, extracted from the pinned bytes and exec’d, never re-typed. See tests/oracle/PROVENANCE.md the RUNNING K3 decay form character-for-character incl. g_min=-5 (6 cases); Eq 1 term by term incl. the carried state (3 shapes, one GVA); the chunked WY construction on BOTH gdn2 chunk arms (3 cases); the output gate is sigmoid; the read scale is the ONLY difference between FLA’s two fixture rows. RED ON PURPOSE: the Kimi-Linear softplus placement (src/lib.rs:268) and the missing read scale (src/lib.rs:646,653, fused.rs:9). 3 reds are the only failures in the file the a_log clamp (src/lib.rs:293) - no source has one, so no fixture case carries an A outside [-10, 20] and a mutant that WIDENS the clamp is invisible here; the recurrent path’s read scale, which has no scale ARGUMENT to fix (kda_step/forward_recurrent take none) so the chunked reds compare the MECHANISM, not the wiring; anything about model QUALITY the two pinned upstream .py files carry no github.com URL because a provenance header would mean editing an upstream file; the URL and the enforced sha256 are in tests/oracle/PROVENANCE.md, and gen_kda_oracle.py exits 2 on PIN ROTED vendor/dormouse-fused/crates/burn-kda/tests/oracle/gen_kda_oracle.py a the upstream it runs (flash-linear-attention@9f38d249, torch 2.14.0+cpu + einops, CPU 2026-09-30). It is the GENERATOR, so it asserts nothing at runtime; its three vacuity guards are what make the fixture non-vacuous and it exits 3 without writing if any fails nothing at runtime (it is not run by cargo). Run by hand: the sha256 of both pinned files, upstream’s recurrent vs chunk references agreeing with each other, the softplus cases separating the two placements of exp(A), and FLA’s executed reference reproducing the alpha=0.0771 that src/lib.rs:58 publishes the crate’s own formulas - it produces the expected values, it does not test them; that is tests/kda_oracle.rs vendor/dormouse-fused/crates/burn-kda/tests/fixtures/kda_oracle.txt a GENERATED by tests/oracle/gen_kda_oracle.py by RUNNING fla-org/flash-linear-attention@9f38d249’s four pure-PyTorch KDA references on CPU (torch 2.14.0+cpu, einops 0.8.2), 2026-09-30. 12 cases: 6 decay gate, 3 recurrent (each at scale 1.0 AND at FLA’s own K**-0.5 default), 3 chunked WY (each at both scales). 9 significant digits, which round-trips f32 exactly nothing by itself; it is the expected-value file for tests/kda_oracle.rs the crate’s own formulas vendor/dormouse-fused/crates/burn-kda/tests/oracle/upstream/fla_ops_kda_gate.py a VERBATIM fla-org/flash-linear-attention@9f38d24980c46d46bd38614e743cdacd21906578 fla/ops/kda/gate.py, sha256 7ea46d62149b8e28e0827e070fee327576de783cb981e3b855182f2b8198c16e. Carries the line ‘This file is modified and supported by the Moonshot AI Team’ (gate.py:8): the KDA decay gate is Moonshot’s own file, not a third party’s nothing by itself; the four reference functions are EXTRACTED from its bytes by gen_kda_oracle.py::extract_def and exec’d, never re-typed the crate’s own formulas. It is not importable as a module (triton at module scope), which is why extraction is used rather than an import no github.com URL in the file because a provenance header would mean editing an upstream file; the URL and the enforced sha256 are in tests/oracle/PROVENANCE.md vendor/dormouse-fused/crates/burn-kda/tests/oracle/upstream/fla_ops_kda_naive.py a VERBATIM fla-org/flash-linear-attention@9f38d24980c46d46bd38614e743cdacd21906578 fla/ops/kda/naive.py, sha256 60a32285d4b67068ff633b48bbe8ab31028066d24f00d27e12199a88fc73f016. naive_recurrent_kda and naive_chunk_kda, the correctness oracle FLA’s own tests compare its Triton KDA kernels against (tests/ops/test_kda.py:20) nothing by itself; both functions are EXTRACTED from its bytes and exec’d, never re-typed the crate’s own formulas no github.com URL in the file because a provenance header would mean editing an upstream file; the URL and the enforced sha256 are in tests/oracle/PROVENANCE.md vendor/dormouse-fused/crates/burn-kda/tests/kda_param_grads_cuda.rs x INSTRUMENT, not an oracle: it asserts GRADIENT ARRIVAL (all 11 groups non-zero, finite) - value fidelity is the two-chunk f64 oracle’s job, see ref_bwd_f64_carry.bin (gen_bwd_f64.py, oracle error 2.3e-12). ALSO cross-checks the fused-vs-central-difference consistency: that reference is derived from the same forward by construction, which is exactly why this row is an instrument and not a tier f64 gradient fixture ref_bwd_f64_carry.bin, GENERATED by tests/oracle/gen_bwd_f64.py (f64 NumPy, oracle error 2.3e-12, c305ec5) PLUS a central difference of the fused forward itself (proves adjoint CONSISTENCY, not formula correctness - formula correctness lives in the tier-(a) kda_oracle.txt row) plus a CPU-autodiff cross-check of the three post-op parameters at 2e-7. Falsified by a detach() at cuda_dispatch.rs:449 killing 8 of 11 parameter groups, restored sha256-identical all 11 KDA parameter groups receive non-zero, finite gradients on the trainer backend at trainer shapes the fused adjoint NUMERICSW beyond consistency (the two-chunk f64 oracle carries that); determinism of the decay path beyond the run-to-run amax record vendor/dormouse-fused/crates/burn-kda/tests/kda_rope.rs a Tier (a) by its own header: RoPE on the KDA q/k path against FLAs OWN rotary reference, pinned as a separate file (tests/oracle/upstream/fla_modules_rotary.py) on purpose, so the pin cannot rot silently into a transcription the q/k rotary application on the KDA path against the authors code whatever the rope test does not assert; see its header vendor/dormouse-fused/crates/burn-kda/tests/oracle/upstream/fla_modules_rotary.py a VERBATIM fla-org/flash-linear-attention upstream rotary module, sha256 6e9d1051751257370fd5f4f95ed4798adab642e1c59a9c0a3540adab440c5115. Carries the upstream MIT header (Copyright 2023-2026 Songlin Yang, Yu Zhang, Zhiyuan Li) nothing by itself; the reference functions are extracted/execd