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

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.
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.
Options Data API
See the canonical product page 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.