Name the optimizer scope before comparing it

The experiment starts with a partition

An optimizer label can hide a second choice: which parameters receive that optimizer. Our current experimental policy has an explicit mixer-output scope. Before asking whether that choice helps a model, the code must identify the intended parameters and account for everything left outside the scope.

On September 20, 2026, we reran the eleven tests in m3a.test_optimizer_policy. All eleven passed. They use small Python objects carrying shape metadata. No tensors, forward passes, gradients, training data or optimizer updates were created.

What the fixture represents

The fixture contains named parameter records for embeddings, mixer projections, gates, normalization and feed-forward weights. The metadata object can report its number of dimensions and element count. It cannot perform a neural-network computation.

That distinction makes the test narrow and inspectable. The question is whether the allocation policy selects the expected named records and leaves a complete partition. It is not whether Muon improves loss, reduces memory or changes training speed.

The observed policy checks

The explicit mixer-output scope supports the plain C0 and C0-GDN2 candidates. Other weights remain assigned to AdamW. Tests verify the default path and the historical scope separately, so an old allocation is not silently reinterpreted as the new experiment.

The suite rejects stacked experimental options, unknown scopes and unsupported candidate combinations. It also rejects missing or extra projection names, unexpected shapes, duplicate names and shared parameter objects. These are fixture results for the current policy implementation, not a universal optimizer-design rule.

Why complete accounting matters

A comparison becomes hard to interpret if the treatment changes more than its label reveals. Accidentally including gate weights, omitting a projection or applying two policies to one shared object can turn the intended experiment into a different one.

The metadata check addresses that bookkeeping risk before expensive numerical work. It records ordered names and exact element counts for the selected scope. Passing it still leaves numerical behavior and model quality unmeasured.

Reproduce only the check described

From mind-1b at the revision in the public receipt, run python3 -m unittest m3a.test_optimizer_policy -v. The receipt includes hashes for the policy and test source. This is an isolated standard-library suite, not permission to run the broader model tests on the local machine.

The next meaningful optimizer result would require a separately authorised, matched remote experiment and its own evidence. No such result is announced here. Read the evidence ledger and the paired-report note to see why a clean setup and a favorable metric remain separate steps.