From a trading idea to a strategy you can actually test

Start with a claim that could be wrong

“Buy strong breakouts” is only an idea. A testable version defines the breakout and measures what happens over a fixed number of bars. A rule that can fail is a rule we can learn from.

Write down why the pattern might work, but keep the story separate from the result. Start by defining the event you can see and the outcome you will measure.

Choose the main time horizon before looking for the best result. If you try many exits, record all of them. Then test the chosen rule on later data.

Write the full set of rules

The rules should let another person make the same decision using only what was known at the time. State the market, session, data and how futures rollovers are handled.

Define when the signal appears, which order is sent, how fills are estimated, how much is at risk and how the trade ends. If a signal needs the bar to close, do not assume a fill at that same close without a real way to get it.

Include the messy cases: missing bars, repeated signals, open positions at the close, rejected orders and gaps through a stop. An entry rule alone is not a complete strategy.

• Universe and eligibility: what can be traded, and when is eligibility known?
• Signal: exact fields, lookback, comparisons and confirmation delays.
• Entry: order type, submission time, expiry and fill assumptions.
• Risk: sizing, stop, aggregate exposure and handling of gaps.
• Exit: targets, trailing logic, time exit and priority when conditions conflict.
• Accounting: commissions, spread, slippage, financing and instrument multipliers.

A simple example

Here is an untested example. Use one market and five-minute bars. When a bar closes above the highest high of the previous 20 bars, enter at the next bar’s open with an allowance for slippage. Hold only one position at a time.

Place the stop below the lowest low of the previous three completed bars. Exit after six bars or when the stop is hit. Close before the session ends. Cancel the trade if the next open gaps beyond the planned stop.

This is enough to start a test, but not enough to trade. We still need correct contract details, costs and data. The benefit is that any disagreement can be traced to one rule.

Observation → explicit rules → executable simulation
→ evaluation on later data → monitored research process

Why can a visually good pattern fail when coded?

We remember the clean winners and overlook the ugly entries and small losses. Code has to take every valid signal. That full set of trades may look very different from the charts we remember.

Manual chart reading often uses details we never wrote down, such as a daily level, time of day or the shape of the earlier move. When simple code fails, find those missing rules instead of adding random filters until the results look good.

Some failures are coding mistakes. Check a small group of winners, losers and unclear trades by hand. Verify times, lookbacks, session breaks and whether the stop or target happened first. Fix mistakes before changing the idea.

How do you avoid turning research into curve fitting?

Overfitting happens when rules are shaped too closely around past noise. Every new filter gives us another chance to improve the old chart. It may also leave too few trades to trust the result.

Build the rule on an earlier period and test it once on a later period. If we keep checking and changing the rule after seeing the later data, it is no longer a fair test.

Look for settings that work across a reasonable range, not one perfect number. Record every version and why it changed. That keeps us honest about how many ideas were tried.

What should we measure besides profit?

Report the number of trades, average winner, average loser, result after costs and drawdown. Look at all the trades, not only the average. A few huge winners can hide a weak strategy, and a cluster of losses can make a good average hard to trade.

Ask two questions: does the idea hold up, and could the fills really happen? Perfect code can still use unrealistic prices. Realistic fills cannot rescue an idea that stops working on new data.

Define a review process before any eventual live use: what is monitored, when assumptions are rechecked, and what conditions stop further deployment of capital? Do not use each losing trade as an excuse to rewrite the system. A pre-defined review schedule helps distinguish ordinary variation from evidence that the original model no longer describes the environment.

A useful test may tell us to reject the idea, get better data or keep studying. We do not need to force every idea into a strategy.