Episode 6: c66, The First Real Anchor

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 focuses on the compression lane that became the current portfolio leader:
baseline_summary.jsonPAPER_BOTS.mdroadmap.jsonRUNS.md, especially the April 10, April 13, and April 18 paper-bot entries
Result Snapshot
The strongest baseline artifact in the repo is c66_opening_compression_option_native_short_balance_dte35_v1.
Recorded baseline summary:
- base OOS return:
0.19181584812500027 - stress-medium OOS return:
0.1669711988 - stress-harsh OOS return:
0.155609875 - OOS trades:
76in all three scenarios - gate decision:
promote - gate reason:
feasible_profile_selected
This is why c66 is first in the paper-bot order and explicitly marked lead_paper_bot.
Strategy Context
c66 is not an isolated invention. It is a modified descendant of the opening-compression family defined around c9_opening_compression_balance_v1. The base idea is to identify a short intraday coil after the open, quantified through a small rolling range over the last few bars, and then trade the first clean expansion out of that coil. The base compression profile already uses range stops, explicit take-profit and break-even logic, early-failure checks, relative-volume filters, and a bounded holding period. It is a structured post-open release model, not a vague "trade breakouts" heuristic.
c66 then makes several decisive changes to that family. It becomes short-only, pushes the option expression out to 2-5 DTE instead of same-day exposure, shortens the maximum hold, demands a slightly cleaner compression pattern, raises the minimum expansion-volume requirement, and adds calmer-day filters through volatility and prior-day range constraints. The profile therefore narrows both the market regime and the instrument choice. That narrowing is probably a large part of why it survives better than the broader compression relatives.
Why c66 Matters
The repo did not promote c66 because it had the biggest isolated PnL anecdote. It promoted c66 because it combined several things that rarely coexist:
- positive OOS result
- stable stress behavior
- meaningful trade count
- operational progress into paper-bot deployment
That combination makes c66 qualitatively different from many attractive research-only lanes. It is more than a positive branch. It is a branch that the repo was willing to operationalize.
What Worked
Two things stand out.
First, the slower DTE compression structure held up better than more speculative or more fragile variants. The repo repeatedly converged on the idea that the strongest compression expression was not the flashiest one.
More precisely, the lane appears to benefit from separating signal timing from gamma sensitivity. A short-only compression release can be directionally correct without needing the explosive convexity of 0DTE or 1DTE contracts. By moving to 2-5 DTE and keeping the signal logic narrow, the branch gives itself more room to survive imperfect intraday timing, while still preserving a tactical options expression. That is a scientifically stronger structure than a same-day lottery framing.
Second, c66 moved beyond research artifacts:
- strict-parity paper-bot validation on
server3 - in-session dry-run smoke
- first live paper deployment on April 13
- restart and cutover after the server reboot on April 18
That progression matters. Research results become much more informative once the branch has to survive operational reality.
What Did Not Work
The negative result around c66 is easy to miss because the branch itself looks strong. The repo also learned that not all compression-related ideas deserve to be grouped together.
For example, the shared feasibility calibration around c52_opening_compression_option_native_balance_v1 still ended infeasible:
- failed
pbo_ok - local failed check
dsr_ok
That stops us from telling a lazy story like "compression works." The better story is:
- one specific slower-DTE short-balance compression lane currently works best
- adjacent compression variants often do not clear the same bar
That distinction should be kept explicit in the public series. The evidence cannot support a family-level victory claim. It supports a narrower statement: one compression descendant, with short-side directional bias, calmer-day filters, and slower-DTE option expression, currently functions as the best anchor candidate in the repo.
Why This Week Matters
This is the first point in the repo where a strategy starts to look like a portfolio anchor rather than a promising experiment.
In One Piece language, c66 is not the treasure. It is the first ship that has earned the right to stay in the fleet.
Public trading research often celebrates every green branch the same way. This repo did not do that. It promoted one branch, kept others behind it, and wired kill-switch logic around the live path.
Public Build Takeaway
If this episode is published well, the audience should come away with a sober but meaningful conclusion:
c66is the best current evidence of a deployable edge in the repo- its value is stability under stress, more than a headline number
- it became important because it survived both research and operational gates
That is what a real anchor looks like in a build-in-public research process.
Related workflow
For the Episode 6: c66, The First Real Anchor 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 6: c66, The First Real Anchor, 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 6: c66, The First Real Anchor 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 6: c66, The First Real Anchor, 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.
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.