Why c4 Was Parked: A Dispersion Strategy That Improved But Still Failed the Portfolio Gate

Daniel Ratke
Research & Engineering

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
The c4 branch is one of the best public examples in this repository because it combines three distinct research realities. First, there was a real implementation problem that distorted the branch. Second, the branch became materially more interesting after that problem was repaired. Third, it still failed the portfolio gate and was parked.
Public strategy research often collapses those events into one vague story. This repo did not. As Episode 8 makes clear, the c4 branch improved after the repair, recovered 79 and 85 trade rows in follow-up work, and still ended with the explicit label park_c4.
The c4 result is best compared with Dispersion and Relative-Strength Backtests: Proxy Series and Data Limits, Backtesting Robustness, and Backtesting Data Quality Checklist. That framing keeps correlation regime, proxy construction, rolling window, split-adjusted bars, sample count, PBO, DSR, and drawdown in the evidence trail.
Question
The useful question is not whether c4 ever looked promising. It clearly did. The useful question is why promise was still not enough.
Most near-miss strategies do not die because they are obviously absurd. They die because they are not clearly additive enough once the full portfolio bar is applied. c4 is a textbook example of that process.
Method: Why c4 Was Evaluated as a Portfolio Candidate Rather Than as an Isolated Winner
The c4 family is a dispersion-relative breakout strategy. It asks whether the primary ticker is breaking its opening structure while outperforming a beta-adjusted proxy by a minimum edge. After the repair work, the branch then had to survive a more complete gate. It was not enough to be interesting on a rerun.
The admission bar, summarized in Episode 8, required:
selection_status=feasible- positive return
trades_per_week >= 1.5orb_overlap_days >= 30c66_overlap_days >= 30offset_ratio_on_orb_down_days >= 0.5- zero extra option attempts
- zero quote rejects
This is why the c4 story is so useful. It shows exactly what happens when a branch is judged as a potential portfolio member instead of as a chart pattern with a nice rerun.
Evidence / Results
The repo's summary now gives a balanced picture. In Toward The One Piece Of Sharpe, c4 is described as a promising research branch whose repaired stock stage restored 79 and 85 trade variants. That is the positive side.
The negative side is the final decision. By April 18, the repo's answer was still park_c4. The branch was not rejected because it was random junk. It was rejected because the combined admission conditions were still too demanding for what the repaired branch could deliver.
This is a much stronger public result than a simple win or loss. It tells the reader what improved, what remained weak, and which exact conditions still blocked admission.
What Worked
What worked was the debugging discipline. The repo did not mistake a launch or storage issue for a strategy conclusion. It repaired the path, reran the branch, and then judged the branch again. That prevented the wrong scientific story.
The branch itself also worked well enough to stay interesting. c4 is not in the same category as the failure-week cemetery of zero-trade or no-feasible-profile lanes. It became a real near-miss, which is why it remains one of the most educational parts of the portfolio journey.
What Failed
What failed was the combined gate. c4 accumulated several smaller deficits rather than one dramatic flaw. Feasibility was still demanding. Overlap and offset requirements were still meaningful. Option parity cleanliness still mattered. The branch did not become clearly additive enough relative to c66 and the broader portfolio goal.
That is an important negative result because many strategies die exactly this way. They do not collapse spectacularly. They remain too ambiguous to admit.
Takeaway
c4 was parked because the branch improved and still did not clear a portfolio-aware gate. That is one of the healthiest kinds of negative result to publish. It shows that the repo is not confusing post-bug recovery with promotion.
If you want the family context, Relative Strength Breakout Strategy: Testing Proxy-Based Intraday Breakouts With QQQ and DIA explains the logic underneath c4. If you want the QQQ-vs-SPY decomposition that made the dispersion branch more legible, Dispersion Trading Backtest: QQQ vs SPY and Why the Signal Was Not Symmetric is the next read. Join the research log to get the next backtest and failure report.
How the terminology applies
For Why c4 Was Parked: A Dispersion Strategy That Improved But Still Failed the Portfolio Gate, 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 Why c4 Was Parked: A Dispersion Strategy That Improved But Still Failed the Portfolio Gate 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 Why c4 Was Parked: A Dispersion Strategy That Improved But Still Failed the Portfolio Gate, 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.
Parking c4 required comparable evidence
The c4 decision needed more than a return comparison. A dispersion sleeve has to preserve the primary ticker, proxy ticker, beta adjustment, signal timestamp, OHLCV aggregates, market session, and relative-strength threshold before it touches options. The option expression then needs point-in-time contracts, selected OCC option symbol, quote window, trade window, spread percent, quote freshness, and reject reasons.
That evidence matters because dispersion failures can hide in the join. The stock leg can look plausible while the option leg fails on NBBO width, no-bid exits, quote condition filters, or low open interest. The proxy can also introduce timestamp drift if the primary and benchmark aggregates are not aligned to the same session and bar boundary.
Parking a branch is easier to defend when the replay manifest shows those fields. It tells future researchers whether c4 was weak because the relative-strength signal was poor, because the option market could not express it cleanly, or because the sleeve overlapped too much with better candidates. Those are different reasons to stop work.
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.

Written by
Daniel Ratke
Research & Engineering
Daniel covers the deeper research notes: options backtesting, execution realism, robustness testing, data engineering, and strategy validation.
Product links
Build the workflow with CuteMarkets
This article is part of the broader CuteMarkets product and research stack. Use the landing pages below to move from the blog into the specific API workflow you want to evaluate.
Beginner options path
Send newcomers to the beginner path for calls, puts, chains, Greeks, IV, and risk.
Options Data API
See the main options overview for real-time and historical options data.
Historical Options Data API
Inspect the historical contracts, quotes, trades, and aggregates workflow.
Options Chain API
Go straight to chain snapshots, expirations, and strike discovery.
Pricing
Review plans before you move from free evaluation into production usage.