Six controls that did nothing
Going through five plug-ins looking for something else, I found that six controls across three of them were completely inert. Read into the engine and thrown away. Move the knob, nothing happens. Twenty-six tests had been passing the whole time, and every single one of them was correct.
What the tests asked
The suite was not thin. It checked that the output contained no NaN and no infinity. That it stayed inside bounds. That it did not click at buffer boundaries. That it was not silent. That it behaved the same at 44.1 and 96 kHz, and the same at a 64-sample block as at 512. That state saved and restored. That the plug-in survived a host tearing it down mid-render.
All of that is worth testing and all of it passed.
Now consider a control that is read from the parameter tree and then never used. The output is finite. It is bounded. It does not click. It is not silent. It is identical at every sample rate and every block size, which is exactly what you would expect from a value that changes nothing.
A dead control passes every one of those tests. Not by luck — a dead control is the best-behaved thing in the codebase. It is the safest possible failure, and that is precisely why nothing caught it.
The question nobody had written down
Every assertion in that suite was about the output: is what came out valid? None of them was about the relationship between input and output: did this input matter?
That distinction sounds obvious written down. It was not obvious for months, because the suite kept going green and green is the colour you stop looking at.
The six were Rumble Tail, Impact and Width in Ground Pressure; Drift and Wobble in Dusted Tape; and Prime Step in The Defwhistler. Six controls, three products, all of them documented, all of them on the panel, all of them automatable from the host. A user could have drawn an automation curve on Width and watched the line move and heard nothing change, and had no way to know whether the fault was the plug-in or their ears.
The fix is a rule, not a patch
Fixing six parameters is an afternoon. The useful part was writing down the rule that would have caught them:
Every declared parameter must be swept across its range, and the output must differ. If it does not, the build fails.
Not a warning. Not a lint. A build failure, because the difference between a warning and a failure is whether anyone deals with it on a Friday. A control that cannot change what you hear is a bug, and it is now a bug the machine finds rather than a matter of opinion.
There is a wrinkle worth mentioning, because it bit immediately. Some parameters are gated by others — Prime Step only has an effect when Prime Tempo is at zero. Sweep it from a default project and you get identical output, which is indistinguishable from a dead control. The sweep has to set prerequisites first, and the test has to say which ones it set, or you have built a machine that confidently reports the wrong answer.
What else the gate learned to ask
Once the rule existed, the obvious neighbours followed. The build now also refuses to publish if the parameter registry, the C++ registrations and the generated documentation describe different instruments — because the original failure was not really about DSP. It was about a claim on a panel that nothing verified.
Twenty-six tests asked whether the software was well-behaved. Nothing asked whether what was published matched what was built.
The part that is still true
All six are implemented and verified live now. Every one of them provably changes the output.
And that is a smaller claim than it sounds. "This parameter changes the output" and "this parameter does something musically useful" are different statements, and only the first has been established. No test can settle the second. Somebody has to listen.
That is the next thing, and it is deliberately not being skipped.
The rule described here is enforced by publish-gate.py, alongside the checks that no build artefact and no unfilled placeholder is ever published. The parameter reference generated from that same registry is on each product page — Ground Pressure has eleven controls, and all eleven now do something.