HomeBlogEpisode 1: Building The Ship
Research SeriesFebruary 22, 2026·3 min read

Episode 1: Building The Ship

CuteMarkets

CuteMarkets Team

Research

Episode 1: Building The Ship

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, this week matters because 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 not just adding 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.