When To Override The Model

A systematic signal says buy. Something about the situation makes you uneasy anyway. The question of when it's right to override the model — rather than trust the process that has presumably been tested and works, on average, over time — is one of the few genuinely hard judgment calls in systematic trading, because getting it wrong in either direction is expensive: override too readily and you've built a slow, expensive way to reinvent discretionary trading with extra steps; never override and you'll eventually let the model trade straight into a situation it was never built to handle.

Situations that usually justify an override

The input data is known to be broken. A price feed glitch, a stale quote, a corporate action the model hasn't been told about yet (a stock split it's about to misread as a 50 percent crash). The signal isn't wrong about the world — it's being fed a wrong description of the world.

A structural event the model wasn't designed to see. A trading halt, a circuit breaker, an exchange outage, an M&A announcement that changes the security's entire character overnight. Most signals are built on continuous, liquid, ordinary trading conditions; none of those descriptions apply during a halt.

A known blind spot you can name in advance. Some models are deliberately built without certain inputs — no earnings-calendar awareness, say — and the desk has a standing rule to reduce size or skip trades around those known gaps rather than trust the signal blindly through them.

Situations that usually don't

"I have a feeling about this one." If you can't point to a specific input that's broken or a specific event the model wasn't built to handle, this is discretion wearing the costume of risk management.

A losing streak. A model losing money for a stretch that's within its expected variance is not evidence it's broken — it's evidence you're watching a process with variance, which every process has.

Hindsight on a single trade. Overriding because the last signal in this name lost money is fitting a rule to one data point, which is exactly the kind of overfitting the systematic approach exists to avoid in the first place.

What makes an override defensible

The same override done once, quietly, and done every time under a written, pre-agreed rule, are different animals even if the trade itself looks identical. A desk that says "we reduce size by half automatically during the ten minutes around any scheduled Fed statement, for every signal, every time" has built discipline into the exception. A trader who decides on the spot, this one time, that today's number "feels different" has reintroduced the very inconsistency the systematic process was built to remove — and has no record of it to review later, because unlike a model signal, a gut call rarely gets logged with the same rigor.

Why the logging matters as much as the rule

A written override policy is only as good as the record of when it was actually used. Every override should be logged with the specific trigger that justified it — which data feed was stale, which halt occurred, which pre-agreed rule fired — and that log reviewed periodically against the model's own performance. This turns the override mechanism into something that can itself be back-tested: did overriding around scheduled announcements actually improve outcomes over the last two years, or did it just feel safer while quietly costing performance? Without the log, nobody can answer that question, and the override policy drifts into being whatever the desk feels like doing that day, dressed up in the language of the original, disciplined exceptions.

The organizational version of the same problem

The tension scales beyond a single trader. A desk that lets any one person override freely, with no sign-off or record, will eventually discover — usually after a loss — that the model's live track record includes trades it never actually made, because a string of the best setups were quietly hand-picked away from it while the worst were left to run systematically. Requiring a second sign-off on discretionary overrides, and reviewing them as a batch each month, keeps the exception mechanism from becoming a second, unaccountable strategy running inside the first one.