Episode 1: Building The Ship

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 earliest part of the recent journey, roughly 2026-02-16 to 2026-02-22.

Evidence note: this episode relies more on commit history and code state than on RUNS.md, because the week is better documented in commits than in run-by-run operations logs.

Result Snapshot

The most important result of this week was not alpha. It was that the repository stopped pretending a low-fidelity options backtest was good enough.

Representative changes visible in commit history:

• 9719eda: use quote fills
• dc68820: add regime detector and repair intraday tests
• 92ab052 and nearby fixes: tighten the engine around edge cases instead of widening the search space

That may sound unglamorous, but it changes the whole scientific meaning of later results. If your options fills are too optimistic or your regime model is absent, your backtest can look sharper than the trade would ever be in the market.

Methodologically, the repository's architecture already separated signal generation from monetization. The signal is typically found on the underlying from completed minute bars, and only after that does the engine attempt to express the setup through an option contract or structure. Once that decomposition exists, quote handling stops being a cosmetic implementation detail. It becomes part of the causal chain that determines whether a reported edge is even interpretable.

What We Actually Built

By this point the repo already had the broad shape described in ALGORITHMS.md: intraday ORB, dispersion and mean-reversion sleeves, plus historical options replay. What changed in this week was not the existence of the engine. It was the seriousness of the execution model.

Three things matter here:

1. Quote-aware execution became a first-class concern.
2. Regime information stopped being an afterthought.
3. Test repair happened close to the engine changes, which means the project was adding more than features; it was trying to make the simulator defend its own assumptions.

In practical terms, this is the difference between "I can replay options" and "I can defend the claim that my replay is not obviously flattering the model."

There is also a deeper scientific point. In intraday options research, model error often enters through execution assumptions earlier than through signal logic. A breakout, reversion, or dispersion signal can be directionally correct and still be economically meaningless if the contract selection, spread, or fill timing is wrong. By moving execution realism forward in the development order, the repo was implicitly choosing external validity over early excitement.

What Worked

What worked in this phase was engineering discipline.

The repo recognized an important asymmetry early:

• a false negative wastes time
• a false positive wastes months

For that reason, tightening fills and regime handling was rational even if it made later research look worse. A causal engine is allowed to disappoint you. A flattering engine is not.

What Did Not Work

What did not work was the implicit earlier assumption that intraday options research could be trusted without a more explicit execution model.

This is not a criticism of the earlier code. It is a statement about research maturity. Many early-stage trading repos start with bar-based convenience and only later discover that execution realism is the actual bottleneck. This repo reached that conclusion quickly.

That negative result deserves to be published clearly:

• early options research is often directionally useful
• it is rarely promotion-grade until fills, selection, and slippage are treated seriously

Why This Week Matters

If we borrow lightly from One Piece, this was the shipyard episode. No treasure was found. No island was conquered. But the crew stopped sailing on driftwood.

The later portfolio discussion only makes sense because of weeks like this one. Without them, later positive results would be less believable and later negative results would be impossible to interpret.

Public Build Takeaway

The build-in-public lesson from Episode 1 is simple:

• report infrastructure weeks honestly
• say when the model is not ready for performance claims
• treat execution realism as research, not as cleanup

The project did not start the last two months by finding a winner. It started by making it harder to lie to itself. That is the correct first step.

That is why this episode should read as research, not as prologue. The data structure of the journey matters. If the early weeks had optimized profile count before execution realism, every later positive result would carry an unspoken asterisk. By reversing that order, the project made later claims narrower but more defensible.

Related workflow

For the Episode 1: Building The Ship 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 1: Building The Ship, 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 1: Building The Ship 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 1: Building The Ship, 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.

The first ship needed a manifest

Episode 1 starts before the later audit language, but the same discipline applies. A research loop needs a manifest that names the dataset, symbol universe, aggregate bar schema, signal timestamp, cache key, and run version. Once options enter the loop, the manifest also needs contract symbology, selected OCC option symbol, quote-aware fill policy, and reject reasons.

That framing keeps the early story technical. The point was not to build a heroic first model. It was to make future mistakes observable. A system that stores response envelopes, pagination cursors, market sessions, and data-quality rejects can survive the next audit because the evidence is already attached to each run.