Episode 5: From Frontier Search To Portfolio Thinking

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.
Read this article with Options Backtesting API, Backtesting Framework, Backtesting Data Quality Checklist, Backtesting Execution Realism, Quote-Aware Options Backtests, and Backtest to Paper Trading Parity Checklist.
Scope
This episode covers the strategic pivot that became explicit in early April.
The key evidence lives in:
RUNS.md, especially the April 6 audit entriesroadmap.jsonPAPER_BOTS.md
Result Snapshot
The decisive phrase from the repo is not a model name. It is the audit verdict:
framework_sound_strategy_mismatch
And the recommended next action:
move_to_new_strategy_ideation
That is the point where the project stopped treating the problem as "optimize ORB harder" and started treating it as "assemble a diversified set of strategies that actually survive the deployability bar."
The roadmap then made the portfolio goal explicit:
- build a small diversified paper-bot portfolio
- stop broad standalone ORB frontier search as the main path
Scientifically, this is a change in objective function. The project stopped optimizing for the best-looking isolated branch and started optimizing for a candidate set that could plausibly coexist under overlap, robustness, and deployability constraints. That is a much harder problem, but it is also a much more realistic one. A live portfolio does not care whether one backtest looked beautiful if that sleeve adds no diversification or fails under operational scrutiny.
Why The Pivot Happened
The repo had accumulated enough evidence by this point to justify a strategic change:
- March realism fixes made results harsher
- ORB audit narrowed what was still defensible
- complement branches were beginning to fail quickly
- the remaining interesting lanes did not all look like ORB
That creates a classic systematic trading choice:
- keep optimizing the incumbent family because it is familiar
- or switch from single-family frontier search to portfolio assembly
This repo chose the second path.
What Worked
What worked was the willingness to name the problem correctly.
The portfolio roadmap did not say "best ORB." It said:
c66lead paper botc4next candidatec36backup candidateQQQdispersion remains research-only
That is already a portfolio mindset. These models are not clones. They are being evaluated partly on their ability to coexist.
The repo's later gates use overlap days, correlation context, sample density, quote realism, and operational parity as part of the promotion logic. Once those dimensions matter, a branch can be economically interesting and still not deserve a slot. The public series should keep returning to that point because it is central to the research philosophy the repository eventually converged on.
This is one of the strongest scientific signals in the repo because real trading systems do not get paid for having one beautiful backtest. They get paid for having a basket whose members are credible together.
What Did Not Work
What did not work was the implicit earlier hope that the project would discover one dominant ORB configuration and then merely scale it.
The audit and roadmap jointly reject that.
The practical negative result is:
- strategy families were failing under a legitimate deployment bar
- more sweeps inside the same family were no longer the highest-value use of time
That is a hard decision to make in research because it often feels like giving up on sunk effort. In fact, it is the opposite. It is refusing to protect sunk effort from evidence.
Why This Week Matters
This was the week the repo got a portfolio objective, more than a model objective.
In restrained One Piece language, this is where the journey stops being about the strongest fighter and starts being about the crew.
One strong but highly correlated or fragile strategy is not the One Piece of Sharpe. A low-overlap basket of believable models is much closer.
Public Build Takeaway
The public lesson from Episode 5 is worth stating directly:
- when the evidence says the family is mismatched to the bar, pivot
- define the portfolio before you define the victory speech
- treat negative model evidence as a budgeting signal
This repo changed more than direction. It changed the question. That is often the highest-leverage move in systematic research.
Related workflow
For the Episode 5: From Frontier Search To Portfolio Thinking workflow, continue through Options Backtesting API, Backtesting Framework, Backtesting Execution Realism, Backtesting Data Quality Checklist, Quote-Aware Options Backtests, and Backtest to Paper Trading Parity Checklist.
How the terminology applies
For Episode 5: From Frontier Search To Portfolio Thinking, 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 research 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 Episode 5: From Frontier Search To Portfolio Thinking 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 Episode 5: From Frontier Search To Portfolio Thinking, 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.
Portfolio candidates still start as rows
Episode 5 moved the research from isolated winners toward portfolio thinking, but the unit of evidence was still a market-data row. Each candidate sleeve should keep its signal timestamp, selected contract, quote window, trade window, cache key, and reject history. Portfolio construction can compare sleeves only after the underlying artifacts agree on schema version, contract symbology, entitlement state, and fill policy.
That requirement matters when two sleeves look complementary. If one sleeve uses clean NBBO quotes and another relies on aggregate bars without top-of-book evidence, the correlation estimate is not comparing like with like. If one branch counts no-bid exits and another silently drops them, the drawdown comparison is also distorted. Portfolio review should therefore include spread percent, stale quote rejects, quote condition filters, trade condition filters, rate-limit assumptions, and the exact replay manifest.
The practical standard is simple: a sleeve should not enter a portfolio because its curve looks different. It should enter only after the evidence record proves that its difference survives the same contract selection, quote-aware fill model, and operational rejects used by the rest of the book.
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.