Turning small-cap trading ideas into repeatable research

I asked Claude Code to apply an existing research methodology to my small-cap data and build a fresh adaptive discovery system. The request was to use rolling evaluation, monitor whether a pattern was weakening and preserve the work for later sessions. Reusing a collection of old scripts was not the brief.

The result was a Python and DuckDB prototype that turns a trading idea into a named test. DuckDB does the table calculations in SQL; Python generates candidates and collects the comparisons. The system can test individual conditions and combine selected conditions into pairs or triples.

One candidate is easier to explain than a list of modules.

A price gap becomes a testable condition

gap_dn_green_fb describes a share opening more than 2% below the previous session, followed by a first one-minute bar that closes above its own opening price. The candidate tests the long direction, buying in the expectation of a rise.

Its stored condition is:

f.gap_pct < -2 AND f.first_bar_green = 1

That name stays attached to its filters and results. A later combination can add another condition without losing track of what the original test meant.

The data preparation makes one row per symbol and trading session from one-minute bars. It also prepares prices at timed exits for comparison. Session times use America/New_York, with a 09:30 to 16:00 filter, rather than a fixed UTC offset that would ignore daylight-saving changes.

Timing matters even in a compact daily row. A condition using the first five minutes cannot justify an entry before those minutes have happened. The feature-to-entry timing still needs a complete audit before treating these research calculations as executable trades.

A cheap share makes the same commission more expensive

The cost model charges $0.005 per share on entry and again on exit, plus 0.05% slippage on each side. Slippage is the assumed difference between the modeled price and the price a trade could actually receive.

cost_pct = (0.005 / entry_price * 2 + 0.0005 * 2) * 100

At a $2 entry, those assumptions cost 0.6% round trip. At $10, they cost 0.2%. The per-share commission has a much larger effect on the cheaper share. Using the candidate's entry price keeps that difference in the comparison.

These are research assumptions. They are not a claim about real fills or an account's fees.

A candidate needs more than a good combined total

The validation code compares years, removes a strong year, increases costs and checks sensitivity to extreme observations. That makes it possible to see whether one period or a handful of trades carries the result.

One check also exposes a reporting problem. If either the bullish or bearish group has fewer than 20 trades, test_regime_stability() records “insufficient data” but returns passed=True. That Boolean does not distinguish a completed successful comparison from a comparison that could not be made.

I would give insufficient evidence its own outcome before using the pass count to rank candidates. That is pending work, not a repair already made. The research also revisited historical years during selection, so those years cannot later serve as untouched tests.

A recorded development run had 67 passing unit tests. The research history also contains failed robustness checks and deterioration in later data. Those are different results: the research machinery existed, but an attractive candidate did not become an established trading strategy.

I asked for the methodology and pitfalls to be documented so a fresh session could continue with less occupied context. That record preserves the candidate definitions, failed ideas and open checks instead of starting the exploration again from a promising headline number.