Found by fresh review of #1121. Not a defect in the device arm itself — the
kernels and the staging are genuinely gated. The gap is the wiring that turns
them on in production.
The evidence
Two mutations applied to the shipped code, built, and run against the full suite:
| mutation |
result |
on_device = false in Music3DenoiseChunks — the production call site disabled |
test_minimax_music3_acoustic 32/283, _speech 9/223, test_speech_engine 11/38 — all GREEN, unchanged |
half_set() → false — the arm refusal disabled |
same three suites — all GREEN, unchanged |
Per .agents/verification.md, a gate that survives deleting its production call
site "is measuring a class rather than a capability, and that is a finding."
What IS covered, so this is scoped honestly
DitForwardDevice and StageMusic3DitWeights are covered by a reduced-dim unit
gate and a full-scale parity gate on both arms. Eight other mutations against
them all go RED (causal attention, half-swap removal, rope sin/cos order,
is_neox_style, zeroed conditioning, the stage-size guard, the release-host
capacity check, the merged-gemm allowlist entry).
What is NOT covered
Music3DenoiseDeviceArm — the production selection path- its half-set refusal,
minimax_music3_speech.cpp:200-205
- the engine's
release_host=true staging, minimax_music3_speech.cpp:579-585
So a change that silently stopped the DiT reaching the device — or that removed
the refusal protecting a partially-staged arm — would be invisible to every gate
in the tree. The arm would quietly run on the host and every number would still
look right, which is the same shape as the dequant-fallback and mute-skip traps
this row has already hit twice.
Owed
A gate that drives the engine through Music3DenoiseDeviceArm and asserts the
device path was actually taken — an invocation count or resident-dtype assertion,
not just output equality, since the host and device arms agree numerically by
design and output alone cannot distinguish them.
Found by fresh review of #1121. Not a defect in the device arm itself — the
kernels and the staging are genuinely gated. The gap is the wiring that turns
them on in production.
The evidence
Two mutations applied to the shipped code, built, and run against the full suite:
on_device = falseinMusic3DenoiseChunks— the production call site disabledtest_minimax_music3_acoustic32/283,_speech9/223,test_speech_engine11/38 — all GREEN, unchangedhalf_set() → false— the arm refusal disabledPer
.agents/verification.md, a gate that survives deleting its production callsite "is measuring a class rather than a capability, and that is a finding."
What IS covered, so this is scoped honestly
DitForwardDeviceandStageMusic3DitWeightsare covered by a reduced-dim unitgate and a full-scale parity gate on both arms. Eight other mutations against
them all go RED (causal attention, half-swap removal, rope sin/cos order,
is_neox_style, zeroed conditioning, the stage-size guard, the release-hostcapacity check, the merged-gemm allowlist entry).
What is NOT covered
Music3DenoiseDeviceArm— the production selection pathminimax_music3_speech.cpp:200-205release_host=truestaging,minimax_music3_speech.cpp:579-585So a change that silently stopped the DiT reaching the device — or that removed
the refusal protecting a partially-staged arm — would be invisible to every gate
in the tree. The arm would quietly run on the host and every number would still
look right, which is the same shape as the dequant-fallback and mute-skip traps
this row has already hit twice.
Owed
A gate that drives the engine through
Music3DenoiseDeviceArmand asserts thedevice path was actually taken — an invocation count or resident-dtype assertion,
not just output equality, since the host and device arms agree numerically by
design and output alone cannot distinguish them.