Episode 4: ORB After The Audit

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 is anchored in orb_framework_audit_20260310.md.
The question was simple: after the March realism fixes, what actually remained of the ORB family?
Result Snapshot
The short answer is that broad ORB did not survive well. A narrow ORB pocket did.
The audit's strongest surviving pocket was:
- directional ORB
5-7DTE5minute opening rangerangestopreg_offbreakout-open-inside-rangedisabled
What failed broadly:
- classic close-breakout matrix
- broad touch/open-any matrix
0DTE,1DTE, and2-3DTEbroad lanes10,15, and20minute ORB as generic fixes
That is a sharp conclusion. It means the ORB engine was not worthless, but the broad frontier was.
Strategy Context
The audit describes what ORB means in this repository in code-faithful terms. The engine builds an opening range from the underlying's first regular-session minute bars, measures range width and early context, scans for a breakout or reversal setup after the range completes, and only then selects an option contract if the strategy is being monetized with options. Entries occur on the next bar after the signal, not on the signal bar itself. That structure means most of the model family is really an underlying-bar signal generator with an option-expression layer added later.
Once ORB is defined that way, the failure of broad ORB search becomes easier to interpret. The search space was testing more than direction. It was testing combinations of opening-range duration, stop geometry, breakout gating, DTE buckets, relative-volume filters, and context overlays. A family that broad will often generate apparent winners under permissive assumptions. After the March audit, the repo learned that only a narrow region of that space remained defensible.
What The Audit Clarified
The audit separates framework and strategy questions.
Framework-side improvements were real:
- causal option fills improved
- base option costs were threaded more consistently into research windows
- parity was materially better than before
But the audit also says clearly that several ORB weaknesses are strategy-design problems, not framework bugs:
- default stop geometry is often unusually wide
require_breakout_open_inside_rangeis a major trade suppressor- mixed DTE lanes make interpretation muddy
That distinction matters. If you blame everything on the framework, you keep rerunning a weak idea. If you blame everything on the strategy, you miss real infrastructure flaws. This audit did the harder thing and tried to separate the two.
What Worked
What worked was narrowness.
The surviving ORB branch was not a broad family win. It was a constrained pocket with specific geometry and DTE assumptions. That is scientifically healthy. Robust strategy research often ends with a narrower thesis than the one it started with.
The audit also reported parity improvements:
bar_open:13/18exact matcheslive_poll_c30_l10:15/18exact matches
That does not mean live and backtest were identical. It means the remaining differences were increasingly about timing and calibration, not about phantom setups or missing contracts.
What Did Not Work
What did not work was the hope that ORB could be saved by one more broad matrix.
The audit is almost an anti-hype document:
- framework not dead
- search space mostly weak or sparse
- surviving branch narrow and specific
That is the correct tone. If you publish ORB work honestly, this is what readers need to see: the failed space beside the one cluster that looked okay, but the larger space that failed.
Why This Week Matters
This is the episode where the project learned that "ORB" was too broad a noun.
There is no single ORB result in this repo worth discussing as if it generalizes across windows, DTE buckets, stops, and filters. There is a much smaller claim:
- under realistic constraints, one constrained ORB pocket still had life
- the broad family did not
That is still useful. In One Piece terms, the crew did not find the treasure island. It found one narrow current that did not sink the ship.
Public Build Takeaway
The lesson from Episode 4 is that narrowing is progress.
Publicly, the best framing is:
- broad ORB did not survive honest testing
- one constrained branch survived better than the rest
- this changed how the repo allocated research time
That is not a retreat. It is what disciplined exploration looks like.
It is also a useful correction to how ORB is usually discussed online. ORB is often treated as though it were a single strategy with minor parameter variations. The evidence here suggests the opposite. ORB is a strategy family whose members can have very different statistical behavior once one enforces causal entries, realistic option monetization, and explicit deployment gates.
Related workflow
For the Episode 4: ORB After The Audit 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 4: ORB After The Audit, 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 4: ORB After The Audit 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 4: ORB After The Audit, 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.
ORB repair depended on row discipline
Episode 4 narrowed ORB because the audit forced each setup into a stricter row. The opening range had to carry underlying OHLCV bars, market session, signal timestamp, and entry timing. The option expression had to carry point-in-time contracts, selected OCC option symbol, NBBO quote, spread percent, quote condition, trade condition, and no-bid exit policy.
That row discipline is why the result became narrower instead of louder. Some variants failed because the signal was weak. Others failed because the option market could not support the fill. Keeping those failures separate made the surviving ORB lane smaller, but it also made it easier to explain and retest.
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.