In each case, nothing was obviously “wrong.” The metrics were real. The thresholds made sense. The logic was locally defensible. What broke was timing.
To make this concrete, I built a tiny toy system with a feedback loop. It reacts immediately to a noisy signal by taking action, and that action feeds back into the signal. There’s no bug in the logic, just immediacy.
Conceptually, it looks like this:
signal = noisy_input() if signal > threshold: take_action()
When this runs inside a feedback loop, the system oscillates. Not because the threshold is bad, but because the decision happens before the signal has stabilized.
Now add one constraint: the decision is only allowed to exist if the condition persists over time.
window = recent(signal, N) if mean(window) > threshold and variance(window) < limit: take_action()
No prediction, no learning, no global state. Just persistence.
The oscillation disappears.
What surprised me is how often this shows up in real systems. Treating decision timing as an architectural concern, rather than a tuning problem, seems to explain a lot of brittle behavior I’ve seen in production.
I’m curious how others here handle this in practice. Do you rely on hysteresis, persistence windows, explicit “not-yet” states, or something else entirely? And where have you found immediate reaction to actually be the right choice?