Episode 2: Speed Before Alpha

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 roughly 2026-02-23 to 2026-03-01.

Evidence note: like Episode 1, this week is best reconstructed from commit history plus the current repo layout rather than from detailed run logs.

Result Snapshot

The headline from this week is that research velocity and observability improved materially before any claim of model quality improved.

Representative commits:

• 2fd8f2e: massive performance improvement, recorded as 20x
• 65cef9f: dashboard and more tests
• 3025b99: RAM and CPU usage collector
• 12186dd: dashboard runner
• d901d12: recommendations in the dashboard

The scientific point is straightforward: broad model exploration is not credible if the system is too slow to rerun, too opaque to audit, or too fragile to compare runs cleanly.

From a research-design perspective, speed and observability reduce two different forms of error. Faster iteration lowers the cost of rerunning a hypothesis under slightly changed assumptions, which reduces the temptation to overfit one lucky run. Better observability lowers the chance that an infrastructure failure, timeout, or partial data path gets misread as a genuine strategy outcome. In systematic trading work, those two errors are often entangled.

What We Actually Changed

The repo spent this week making research operationally visible.

That included:

• faster experimentation loops
• a dashboard surface for monitoring runs
• system telemetry for CPU and memory
• clearer recommendation outputs

These are not cosmetic improvements. A research process that cannot track resource use and compare repeated runs is vulnerable to three common errors:

• misdiagnosing infra failures as strategy failures
• abandoning good ideas because the run path is too slow
• believing noisy results because the cost of reproduction is too high

The repository already had a large model vocabulary by this point, with ORB, mean-reversion, dispersion, and daily forecast families all implemented in some form. Once a codebase reaches that stage, the marginal value of one more profile is often lower than the marginal value of being able to compare, rerun, and diagnose the existing ones. This week is best understood as the point where the repo started optimizing the laboratory, more than the experiments.

What Worked

What worked here was the decision to spend engineering time on throughput before widening the model frontier further.

This is especially important in a repo like this one because the implemented strategy set is already broad. ALGORITHMS.md shows ORB, dispersion, mean reversion, and daily Carver-style families. Once that many model families exist, the bottleneck shifts from "can we code one more setup?" to "can we compare and reproduce what we already have?"

The answer this week was yes, increasingly.

What Did Not Work

What did not work, or at least what the repo implicitly rejected, was the idea that faster research automatically means better research.

This is an important negative result to publish because it is one of the easiest traps in systematic strategy work. If a new cluster, faster DuckDB path, or nicer dashboard leads directly to more profiles and more sweep variants, the temptation is to confuse throughput with signal.

The later repo evidence shows that did not happen here. Speed created the conditions for better falsification, not for easier self-deception.

Why This Week Matters

In One Piece terms, this was the navigator-and-logbook week. The ship was more than seaworthy now. It had instruments.

The next stages of the repo become much harsher:

• realism audits
• ORB audits
• promotion gates
• cross-host reproducibility

None of that works well if the system cannot surface what happened during a run.

Public Build Takeaway

The public lesson is not "we made the backtester faster."

It is:

• faster iteration lowers the cost of falsification
• dashboards matter because they stop silent failures from masquerading as alpha
• performance engineering is part of research quality when the search space is large

This repository did not spend late February chasing a miracle trade. It spent late February making sure the later search could be audited, repeated, and survived by the people running it.

That is a scientific style worth keeping in the public series. The audience should be shown that performance engineering, telemetry, and dashboarding were not detours from alpha research. They were preconditions for any later statement about alpha to be taken seriously.

Related workflow

For the Episode 2: Speed Before Alpha 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 2: Speed Before Alpha, 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 2: Speed Before Alpha 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 2: Speed Before Alpha, 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.

Speed still needed market structure

Episode 2 was about moving quickly, but speed only helped because the early system started forming a repeatable data structure. A fast loop still needs a symbol universe, aggregate bar schema, signal timestamp, cache key, and replay file. Once options enter the picture, it also needs contract symbology, OCC option symbol, quote window, trade window, and a clear difference between top-of-book quotes and trade prints.

The useful lesson is not that a researcher should run as many experiments as possible. It is that experiments should be cheap to run and cheap to reject. That requires response envelopes, pagination cursors, rate-limit assumptions, and data-quality rejects to be visible even in early prototypes. A fast result with no schema is just another anecdote.

This is why the later simulator audit did not feel like a separate phase. The early work had already taught the repo that every promising branch needed a stored object trail. The audit simply made that trail stricter: point-in-time contracts, NBBO evidence, quote conditions, trade conditions, and no-bid exits had to be part of the loop.