Solving a problem you don't have

A proposal came up to replace moving averages with a Kalman filter: smoother trend estimate, less lag, better behaviour at turns. All of that is true. The Kalman filter is a genuinely better tool for the job it does.

We didn't build it, and the reason took about a minute to arrive at once somebody asked the right question.

Which rule consumes it?

None of them did.

The engines are zone and inventory models. They ask where price has done business, where it has been accepted and rejected, and how positioning going into a session constrains what the session can plausibly do. Not one rule anywhere in them takes a trend estimate as an input. There was no consumer.

A better estimate of a quantity that nothing reads is not an improvement. It is a correct answer to a question the system does not ask.

Why this is easy to miss

Because the proposal was good. That is the whole trap. Everything about it was defensible in isolation: the existing method is cruder, the replacement is better understood, the literature is solid, and the implementation is tractable. At no point does the idea look bad.

Sophistication is legible as progress in a way that "we considered it and it changes nothing" is not. You can show someone a Kalman filter. It is much harder to show them the afternoon you didn't spend on it.

Method searches are particularly prone to this because they generate real, visible work. You end up with a comparison, some plots, a defensible conclusion — and no change to any decision the system makes.

The question to ask first

Before evaluating whether a method is better, establish what it would change:

• Which existing rule takes this as an input?
• What decision comes out differently once the input improves?
• Is that decision one where the current input is actually the binding constraint, or is something else dominating?

If the first question has no answer, stop. The remaining two are moot and the comparison is entertainment.

That third question is the subtle one. Sometimes a rule does consume the quantity, but the quantity isn't what's limiting it — the sizing is wrong, or the timing window is too wide, or the rule fires so rarely that estimator quality is swamped by sample noise. Improving a non-binding input is the same mistake in a less obvious costume.

Motivate from a constraint, not from a method

The healthy version of this runs backwards. You notice a rule behaving badly in a specific, describable way. You work out which input is responsible. Then you go looking for a better version of that input, and now you have both a reason to search and a test that will tell you whether the search worked.

Starting from the method — we should use a Kalman filter — inverts that. You arrive with a solution and go looking for somewhere to put it, and because the solution is good you will usually find somewhere plausible. Plausible is not the same as binding.

Keep the rejections

We keep a list of ideas we decided not to build, each with the reason. The Kalman filter is on it, and so is the sentence about no rule consuming a trend estimate.

This matters more than it sounds. A good idea that was rejected for a contextual reason will be re-proposed, by someone else or by the same person a year later, and it will look just as good the second time — because the argument against it was never about the idea's quality. Without the written reason, you re-run the whole evaluation and reach the same answer at the same cost.

The rejection is the finding. It is worth as much shelf space as the things that worked, and it is cheaper to store.