Peter's Build Rules

1. Benchmark first

GSB's genetic search gives different results each run, even with identical settings. In one of Peter's tests, 20 identical YM runs put anywhere from 25 to 103 systems in Favorites B. So a single run tells you very little.

• Build a benchmark with your current settings.
• Change one setting, then run the comparison 4 times. Peter runs every comparison four times.
• Four builds of 50,000 aren't the same as one build of 200,000: each run settles on its own indicators.
• Keep a test log, and save each test as its own .gsboptset file.
• Protect your master settings file. Peter once lost a month of research to an accidental date change in his.

2. Choosing the market and session

• Start with a market that has supplied settings. A new market is much more work, and some markets are close to impossible for GSB.
• Three choices matter most: entry type, session time and secondary filter. Settings that suit one market don't carry across to another (Nasdaq settings won't suit gold, for example).
• Build where the volume and range are. Trademaid's SessionTimeCalcs script (in the GSB scripts ELD for TradeStation) prints average range, movement and volume by time of day, so you can see the active hours. Peter also checks a market's daily range (average of close minus open, and of high minus low, over 5 days on day-session bars) before he commits to it.
• Allow entries over the whole session. The best entry time is nearly always the start of the session; leaving out the last 30–60 minutes is optional.
• Use 30-minute bars for any new market. Peter found 1-minute bars very poor and advises against anything under 5 minutes.
• 24-hour data. In 2020 Peter warned against it. He has since relaxed that: he builds 23-hour Nasdaq swing systems and 24-hour gold 60-minute swing systems (2023–25). Day-trading systems are still built on the day session.

3. Data periods

• Start at 1 January 2007 for most markets (for ES Peter sometimes goes back to 2001). Start once the market was liquid, and never build on a year or so of data.
• The in-sample period you choose indicators on must be the same as the in-sample period you build on.
• Keep the most recent year or two completely unseen by GSB.
• Peter leaves data after 28 February 2020 out of his builds, so the 2020–22 volatility isn't curve-fitted.
• Never train only on 2007–2009: the financial-crisis volatility isn't typical.
• Percentage training splits (such as the 40% files) are only for a first look at a market. Peter holds data out with Nth days and later dates instead.

See Validation and Robustness for how out-of-sample data and Nth-day mode fit together.

4. Strategy settings Peter keeps fixed

These are the Strategy panel settings he leaves alone in nearly every build. Each is explained on the Interface Reference.

Don't turn every option on. In one of Peter's tests, 200,000 systems built with nearly everything enabled put no systems at all in Favorites B, while honed 2,500-system tests put more than 200 there.

The same goes for indicators, and it costs speed as well. In 2023 a member who switched on every indicator (166 at the time, against his usual 117) saw build speed fall from over 1,000 systems a minute to 100–200, and an overnight 50,000-system pass reached only about 8,000. The two-pass method below exists so the main build only carries a short list.

5. Indicator selection in two passes

1. Pass 1 picks about 10 indicators, using the greenMax10 macro supplied with the 2025 settings files.
2. Pass 2 builds systems with only those indicators.

• Rank indicators in the indicator statistics by frequency first, then ratio. The marginal ones change between identical runs, so the exact cut-off isn't critical.
• Stop after one or two reduction loops. Peter calls more than that a waste of time.
• Don't use the green10Fav300 macro; Peter rejected it in 2023. (greenMax10 is a different macro and is fine.)
• Using 3 indicators in pass 1 is faster, but lets weaker indicators slip through.
• The short-cut method (build the indicator list once, then build systems from it twice) saves about half the CPU time. Peter briefly planned to remove it in 2023, then reversed that: his view is it has no downside.

The macros are covered on Macros Overview.

6. Stops, targets and exits

• Build with a big stop, about $2,000 per contract for ES, NQ and most markets. Peter's earlier (2018) advice was to build without a stop; he now says not to, because a few huge trades skew the genetic search. Optimise the stop last, in TradeStation or MultiCharts, looking for a range that works rather than one best value.
• Day trading: no profit target, or only a small one to get more test trades. Profit targets are for swing systems.
• Day trading: leave the extra exit modes off. The market-on-close exit is, in the words of a member Peter agreed with, the most robust part of a day system.

7. Build size and selection

• 2,500 systems per test is enough (the 2025 supplied SysBuild files use 2,500 per pass).
• 20,000 systems is what Peter uses when building systems he means to use.
• Never 50,000 in one go: the top 300 end up too similar to each other, and the window struggles.
• Put the top 300 into Favorites A, then group them into families.
• Judge whole families. Peter's earlier advice was to walk forward only the top member of each family. Since 2021 he looks at every member out of sample and walks several forward, because the spread across members tells you something. Trade one member per family.
• Select on NP/DD, Pearson and the walk-forward curves (see Selecting Trading Systems and Walk-Forward Optimization).
• Test any selection rule. Split your ~300 systems into the top third and bottom third by your rule and compare their out-of-sample results. If the top third isn't clearly better, the rule isn't helping.

8. Improving one system by hand

Peter's preferred way to refine a chosen system is in TradeStation or MultiCharts, one module at a time:

1. Test every logical part of the system (each indicator, filter and stop) on its own.
2. Optimise every input by hand, or use GSB's AI walk-forward parameter analysis.
3. Remove any part that changes only a handful of trades. Two trades out of 1,000 isn't a valid improvement.
4. With AnyIndicatorCrossed or Cross entries, comment out 2 of the 3 indicators (//v2=…;, //v3=…;) and note net profit, drawdown and profit factor for each indicator alone. For the Cross entry type, first change the result line to result = Sign(Sign(vn1)+Sign(vn2)+Sign(vn3));. Some systems then give zero trades, so the logic may need adjusting.
5. Use Trademaid's GSB_PerformanceMetrics strategy (October 2024) for before-and-after numbers.
6. Keep an added filter only if its optimisation forms a smooth bell curve and it removes about 10% or more of trades while improving the results. It's more convincing if it works on several systems and on both longs and shorts.
7. Add day-of-week filters last, and re-optimise with all days included.

9. Long, short and day of week

• Peter prefers to build long-and-short systems, then switch off the weaker side, rather than build long-only and short-only systems. A one-sided build has about half the trades, so a smaller sample.
• GSB's LSR column (long/short ratio, from build 64.76) shows which side is stronger.
• Building on day-of-week subsets is valid with more than 300 trades. Loosen the Pearson and trade-count filters, since one day is about a fifth of the data.

10. Common traps

Further reading on the Trademaid forum

• Update to GSB methodology (Peter's long-running methodology thread)
• GSB beta builds (release notes, including the supplied settings files)
• General support questions

Next Steps

Put your shortlist through its paces on data it hasn't seen: