Many automated trading systems begin with a natural question:
Will the next market resolve Up or Down?
There is nothing wrong with that question.
The longer I work on short-horizon systems, however, the more important a second question becomes:
Should this market be traded at all?
That small change turns the strategy into a different kind of decision system.
From two outputs to three
The simplest BTC 5-minute directional bot has two states:
UP
DOWN
Every market window must receive an answer.
The hidden assumption is:
There is always a direction worth betting on.
I do not think that is a safe assumption.
In our system, a candidate signal is reviewed again through market context, internal state, conflict handling, and post-signal logic.
At a high level, the final action can be understood as:
KEEP
ADJUST
STOP
or simply:
trade the candidate
modify the candidate
do not trade
In the public historical snapshot, 348 of 18,633 signals ended in STOP, roughly 1.87%.
Those events are not software failures.
They are valid strategy outputs.
Why a signal is not a trade
A signal can have a good historical profile and still become questionable in a specific instance.
For example:
- the current market environment may not resemble the conditions where the signal was strongest;
- local structure may change after the initial candidate appears;
- multiple candidate families may conflict;
- data may be incomplete;
- similar triggers may become unusually concentrated;
- risk or execution conditions may fail.
If the strategy says:
I saw Up a moment ago, therefore I must still buy Up,
it has not answered the more useful question:
Is this Up candidate still worth trusting now?
That is what I mean by Signal ≠ Trade.
A signal is a proposal.
An order is what survives the full decision chain.
NO TRADE is not cowardice
A natural objection is:
What if a STOP blocks a trade that would have won?
That will happen.
Every filter creates two kinds of mistakes:
- it rejects some trades that would have lost;
- it also rejects some trades that would have won.
A filter that magically removes only losing trades and never touches a winner would make me suspicious.
Real research usually involves a trade-off:
take fewer trades
↓
give up some correct opportunities
↓
try to reduce worse risk exposure
The real validation question is:
Does the filter still deserve to exist across longer history, different regimes, and the full strategy?
The dangerous idea: recent losses mean we need a new STOP
This is one of the easiest ways to overfit.
Recent performance weakens.
You open the losing cases.
A common pattern appears.
You write a rule:
Next time this happens, skip the trade.
You rerun the recent sample and the result improves.
That process feels convincing because you already know which trades lost. Once the answer is visible, it is almost always possible to invent a reasonable explanation.
But explanation is not generalization.
In our internal research, we have rejected a candidate designed around a recent weak period even though it looked locally useful. It did not pass broader acceptance criteria around full-strategy drawdown, loss streaks, and historical selection robustness.
The final decision was:
Do not ship it.
Rejected ideas are part of the strategy too.
Why we do not publish exact STOP logic
We can discuss:
- why STOP exists;
- where it sits conceptually in the decision process;
- how we evaluate a filter;
- historical aggregate STOP counts;
- the difference between candidate generation and final execution.
We do not publish:
- exact features;
- indicator combinations;
- lookback windows;
- thresholds;
- branch mappings;
- action boundaries;
- internal priority rules.
The principle is simple:
Publish the research process, not the recipe.
A useful STOP may barely move the headline win rate
Some post-signal rules affect only a small fraction of total events.
Their value may show up elsewhere:
- worst-week behavior;
- extreme-path containment;
- loss-streak behavior;
- consistency across time segments;
- avoidance of clearly abnormal contexts.
This is why I do not judge every strategy change by one question:
Did the total score go up?
A rule can improve aggregate score while making drawdown worse.
Another can barely improve the headline result while making the weakest path more stable.
Those are different upgrades.
Why “trade every market” makes me uncomfortable
BTC 5-minute markets keep arriving throughout the day.
A bot that must trade every window is effectively assuming:
I have an edge in every market state.
That is a very strong claim.
I prefer a system that can say:
no sufficiently strong candidate
→ skip
candidate conflict
→ skip
state not ready
→ skip
risk condition failed
→ skip
execution condition failed
→ skip
The objective is not fewer trades for its own sake.
The objective is selectivity.
Automation should be good at doing nothing
There is a common intuition:
If a bot can run 24/7, it should trade as often as possible.
I think one of automation’s most valuable abilities is the opposite.
A machine can execute “do nothing” without boredom, FOMO, revenge trading, or overconfidence after a winning streak.
Once NO TRADE is a valid system state, the same standard can be applied every time.
That is more interesting to me than simply maximizing the number of predictions.
STOP in the public replay
At the September 1, 2026 public snapshot:
Historical signals 18,633
Executed orders 18,285
STOP 348
STOP rate 1.87%
Full report:
If you only look at the 18,285 executed events, it is easy to miss the layer before execution:
Not every signal should become an order.
For me, that distinction matters more than adding one more indicator.
Related:
A New Rule Looked Great Recently. Why I Still Rejected It.
Project:
This article is for technical research, educational, and informational purposes only. STOP and risk controls can reduce exposure but cannot eliminate trading losses.