HomeBlogAlgorithmic Trading Research Log: How to Build in Public Without Hiding Failed Results
Research LogApril 20, 2026·4 min read

Algorithmic Trading Research Log: How to Build in Public Without Hiding Failed Results

CuteMarkets

CuteMarkets Team

Research

Algorithmic Trading Research Log: How to Build in Public Without Hiding Failed Results

Repository reference: cutebacktests

Abstract

An algorithmic trading research log becomes valuable when it records changing conclusions rather than only attractive ideas. That is the main reason this repository has become more useful over the last two months. The project did not only collect survivors. It also made the simulator harsher, narrowed the strategy map, and published why several branches were closed.

The clearest evidence for that claim is the sequence of documents already in the repo: Backtesting Framework Issue Summary, ORB Framework Audit, Toward The One Piece Of Sharpe, and the Series Index. Together they show a research log changing its mind in public as the evidence changes.

Question

The practical question is not how to publish more content. It is how to publish research in a way that becomes more trustworthy over time.

For trading, that usually means doing the opposite of what marketing encourages. It means publishing bug-fix audits, strategy mismatches, zero-trade branches, and near-misses that still failed admission. Without those pieces, the research log becomes a highlight reel.

Method: What an Algorithmic Trading Research Log Should Contain

The most credible research log in this domain usually contains five elements.

First, it records framework changes that alter the meaning of prior results. The March 8 audit is a model case because it named five patched issues, explained why they mattered, and recorded 91 targeted passing tests.

Second, it records strategic pivots. In Episode 5, the repo moved from broad frontier search toward portfolio thinking under the diagnosis framework_sound_strategy_mismatch.

Third, it records negative results. Episode 7 does this well by listing failed branches together with their blockers, including 0-trade lanes and the LFCM catalyst lane that still found 0 valid catalyst days after the data path was repaired.

Fourth, it records near-misses honestly. c36 and c4 are stronger stories because they were not flattened into either victory or failure. They were explained as profitable but sparse, or repaired but still not additive enough.

Fifth, it records current status clearly. PAPER_BOTS.md and the portfolio roadmap do this by naming c66 as the lead paper bot, keeping c36 as backup, and leaving QQQ dispersion as research-only.

Evidence / Results

This repo already provides a good public-build skeleton:

  • framework realism audit on March 8
  • ORB family audit on March 10
  • pivot from broad frontier search to portfolio assembly
  • failure-week cemetery for c23, c26, c29, c30, c32, c37, and LFCM
  • explicit paper-bot ladder led by c66

That sequence is more informative than a list of green strategies because it shows causal learning. Once the simulator became more honest, broad opportunity claims weakened. Then the remaining credible lanes became more legible. Then the portfolio objective itself got clearer.

What Worked

What worked was publishing negative information as if it were central, not embarrassing. The repo's public artifacts repeatedly show what changed, what failed, and what stayed uncertain. That is exactly how a research log builds trust.

The other thing that worked was specific evidence. The log does not merely say c66 is the best branch. It gives base 19.18%, stress-medium 16.70%, stress-harsh 15.56%, and 76 out-of-sample trades. It does not merely say broad ORB weakened. It names the narrow surviving pocket and the broad lanes that did not hold up.

What Failed

What failed was the idea that credibility comes from certainty. The repo got more credible when it became more selective and more explicit about what died. Several broad or intuitive ideas stopped surviving. The public story improved when those losses were written down.

That is an important negative lesson because many build-in-public trading projects undermine themselves by narrating confidence while hiding reversals. A real research log should sound more precise over time, not merely more enthusiastic.

Takeaway

An algorithmic trading research log becomes worth following when it records the dead ends, the audits, the pivots, and the surviving branches in one place. This repository is increasingly valuable for exactly that reason. It is accumulating evidence about which ideas deserve less attention, not merely stacking new ideas.

If you want the portfolio-level outcome of that process, Building a Portfolio of Trading Models: Why One Good Backtest Is Not Enough and The One Piece of Sharpe: What Months of Intraday Options Backtesting Actually Taught Us are the next two reads. Join the research log to get the next backtest and failure report.