HomeBlogGap Reclaim Strategy Backtest: Why a Good Chart Pattern Failed the Data
ValidationApril 19, 2026·6 min read

Gap Reclaim Strategy Backtest: Why a Good Chart Pattern Failed the Data

Daniel Ratke

Daniel Ratke

Research & Engineering

Gap Reclaim Strategy Backtest: Why a Good Chart Pattern Failed the Data

Term map

Backtesting vocabulary for this article

Treat signal timestamp, point-in-time universe, quote-aware fill, reject reason, replay artifact, walk-forward test, and cache key as first-class terms. They separate reproducible research from a backtest that only preserves the final performance table.

Follow the linked definitions for Point-in-time contracts, Quote-aware fills, Reject reasons, Replay artifact, Cache key, Signal timestamp, Look-ahead leakage, Walk-forward test, Slippage model, Same-bar fill, Promotion gate, and Options data API.

Repository reference: cutebacktests

Abstract

Gap reclaim continuation is one of those strategies that looks immediately believable on charts. A stock gaps higher, finds support, reclaims its early structure, and continues in the direction of the overnight move. It is a clean story, which is exactly why it is dangerous. Clean stories can survive much longer than weak evidence.

This repository's c26 branch is a good example. As documented in Episode 7, c26 required a meaningful gap up, early support hold, and continuation after the reclaim. The quality version increased the minimum gap size, required stronger relative volume, and demanded a larger breakout fraction versus the opening range. The resulting branch still failed DSR, Sharpe, Sortino, PBO, and sample-quality requirements.

For implementation context, connect this gap-reclaim result to Opening Range Breakout Backtesting for Developers, Backtesting Engine Loop, and Backtesting Robustness.

Question

The practical question is not whether gap-reclaim continuation can happen. It clearly can. The useful question is whether it generalizes well enough after the pattern is translated into a measurable strategy object.

Chart intuition is especially strong here. The setup feels selective and event-driven. The problem is that once you define the gap threshold, the reclaim condition, the required relative volume, and the continuation deadline explicitly, the path may stop being robust.

Method: How the Gap Reclaim Strategy Backtest Was Defined

The c26 lane was built on an event-drive variant. It required a meaningful gap up into the session open, then asked whether the market could hold support and continue after the reclaim. The quality version then made the setup more selective by increasing the minimum gap size, requiring stronger relative volume, and demanding a larger breakout fraction versus the opening range.

This is a good design for testing because it makes the pattern falsifiable. The strategy is no longer "buy strong gap-ups that keep going." It becomes a sequence of measurable conditions: overnight dislocation, early acceptance, reclaim quality, and continuation quality.

Evidence / Results

The outcome from Episode 7 is direct:

  • lane: c26 gap reclaim continuation
  • result: no_feasible_profile
  • main blockers: failed DSR, Sharpe, Sortino, PBO, and sparse sample

This is an instructive result because it shows that the branch did not fail due to one absurd implementation choice. It failed after the repo translated an attractive event-momentum narrative into explicit filters and still could not obtain a profile that was both robust and sufficiently active.

What Worked

What worked was the translation of chart intuition into testable logic. Even though the strategy failed, the repo learned something real from it. A generic gap-reclaim continuation story is too vague to evaluate. The c26 branch made it specific enough to reject with confidence.

That is a valuable public result because it prevents future researchers from treating the pattern as an untested blank slate. It was tested here under explicit gap, support, volume, and continuation conditions.

What Failed

What failed was generalization. The branch remained too sparse and too weak on the metrics that mattered. In practical terms, the strategy was better at sounding plausible than at surviving the evidence standard needed for promotion.

This is one of the most important failure types to publish because event-driven continuation ideas often look best in hindsight. The repo's contribution here is that it stopped the conversation from living at the chart-caption level.

Takeaway

The c26 gap reclaim strategy failed the data because a compelling chart pattern is not the same thing as a robust, repeated edge. Once the logic was defined tightly enough to test, the branch did not survive DSR, Sharpe, Sortino, PBO, and sample-quality checks.

If you want the broader cemetery around this result, Failed Trading Strategies: 7 Ideas We Tested So You Do Not Have To is the next stop. If you want the mirror-image reversal case, Gap Up Failure Fade Backtest: The Difference Between Intuition and Evidence continues the comparison. Join the research log to get the next backtest and failure report.

How the terminology applies

For Gap Reclaim Strategy Backtest: Why a Good Chart Pattern Failed the Data, the backtesting workflow should treat Point-in-time contracts, Quote-aware fills, Reject reasons, Replay artifact, Cache key, and Signal timestamp as operational state rather than glossary decoration. That framing keeps the research claim causal: the strategy can only select instruments, prices, and labels that existed at the decision time.

A developer implementing this Validation idea should persist Look-ahead leakage, Walk-forward test, Slippage model, Same-bar fill, Promotion gate, and Options data API beside the result, instead of leaving those words in a term card. It also turns attractive performance into an auditable record where fills, skips, thresholds, and replay inputs can be challenged independently.

The review artifact for Gap Reclaim Strategy Backtest: Why a Good Chart Pattern Failed the Data becomes more useful when OPRA-originating data, OCC option symbol, Bid/ask spread, Midpoint, Quote/trade condition, and Quote vs trade semantics appear in the same body of evidence as the selected rows. When a result is promoted, these fields should appear in the run manifest, rather than a prose summary or final equity curve.

In production notes for this backtesting workflow, REST snapshot, WebSocket stream, Entitlement gate, Quote freshness, Timestamp semantics, and Pagination cursor define the checks that decide whether the workflow is reproducible. The result is a backtest that can be rerun, compared across threshold families, and rejected when the evidence is not strong enough.

For Gap Reclaim Strategy Backtest: Why a Good Chart Pattern Failed the Data, the practical acceptance test is simple: another developer should be able to read the body, identify the exact inputs, reproduce the request sequence, and explain the accepted and rejected rows without relying on the bottom terminology grid. If a phrase appears in the page vocabulary, it should correspond to a stored field, a validation check, a replay step, or an implementation decision in the backtesting workflow.

This is also the reason the article should not measure success only by the final chart, table, or headline metric. The better standard is whether the data path, timing model, entitlement state, and evidence trail survive review. When those pieces are written directly into the body, the terminology becomes part of the workflow readers can implement.

Separating chart failure from data failure

A gap reclaim pattern can look clean on a stock chart and still fail when expressed through options. The replay should therefore store two layers. The stock layer records the open-close state, gap size, reclaim timestamp, OHLCV bars, market session, and any adjusted-aggregate flag. The option layer records point-in-time contracts, selected OCC option symbol, DTE, strike, moneyness, NBBO quote, trade condition, quote condition, and side-specific fill rule.

That split makes the failure easier to read. If the stock signal fires but the option quote is stale, the strategy has an execution problem. If the option market is clean but the reclaim quickly reverses, the strategy has a signal problem. If pagination misses part of the historical chain, the run has a data-quality problem. Those outcomes should not share one generic reject note.

For a future retest, the cache key should include ticker, date, session label, strategy version, option schema version, endpoint, entitlement state, and backfill window. That sounds fussy until a researcher tries to explain why two runs with the same headline setup selected different contracts. The field list is what keeps the failed result reproducible.

Terminology

Market-data terms used in this article

These terms keep the article connected to the CuteMarkets knowledge base and to the exact API workflow behind the research.

Point-in-time contracts

Contract discovery anchored to the research date so a backtest does not use future listings.

Quote-aware fills

Entry and exit assumptions based on bid/ask quotes, quote age, spread width, and side-specific fill rules.

Reject reasons

Logged explanations for skipped contracts or fills, including stale quote, wide spread, no bid, or missing data.

Replay artifact

The saved request, selection, fill, reject, and metric record that lets another developer audit the backtest.

Cache key

The structured identifier that keeps provider, endpoint, ticker, timestamp, plan, and schema state from being mixed.

Signal timestamp

The exact time a strategy made a decision, used to reconstruct the visible universe and quote window causally.

Look-ahead leakage

A research error where a fill, contract, indicator, or label uses information unavailable at decision time.

Walk-forward test

A validation method that repeatedly trains and evaluates across separated time windows instead of trusting one optimized sample.

Slippage model

A fill-cost assumption based on bid/ask side, midpoint, spread percent, quote age, and liquidity policy.

Same-bar fill

An intraday backtest assumption that can become invalid when signal, entry, stop, and target ordering is ambiguous.

Promotion gate

The written threshold that decides whether a research candidate can move into paper trading or production monitoring.

Options data API

The product surface for chains, contracts, quotes, trades, aggregates, Greeks, IV, open interest, and expirations.

OPRA-originating data

The U.S. listed-options source context behind quotes, trades, exchange participation, and consolidated option-market records.

OCC option symbol

The exact option contract identifier that preserves root, expiration, call or put side, and strike.

Bid/ask spread

The execution interval between bid and ask that determines whether a contract is realistically tradable.

Midpoint

The computed center between bid and ask, useful as a reference price but not proof that an order would fill.

Quote/trade condition

The condition-code, exchange, correction, sequence, and timestamp context that explains how a quote or trade row can be used.

Quote vs trade semantics

The distinction between executable bid/ask markets, printed transactions, and bar-level summaries.

REST snapshot

A reproducible request for current or historical market state, used for initialization, backfills, and audit logs.

WebSocket stream

A persistent live connection that needs subscription topics, reconnect tracking, freshness labels, and REST repair paths.

Entitlement gate

The product, plan, quote, live, delayed, historical, or commercial-use boundary checked before data is shown.

Quote freshness

The age, timestamp, and live or delayed state of a bid/ask record before it is used in a scanner, backtest, or UI.

Timestamp semantics

The exchange, provider, ingestion, session, and application time context attached to a market-data record.

Pagination cursor

The continuation token or next URL that keeps large chains, trades, quotes, and historical windows complete.

Daniel Ratke

Written by

Daniel Ratke

Research & Engineering

Daniel covers the deeper research notes: options backtesting, execution realism, robustness testing, data engineering, and strategy validation.