One thing I’d add rather than dispute. The AutoTune machinery assumes a dominant cycle is there to be found, and I couldn’t see anywhere in the post where that assumption gets its own test – no shuffled control, no random-period arm. So the 25% is measured against buy-and-hold, but not against “the same filter, tuned to a period that means nothing”.

I ran that premise separately, on hourly bars of three majors, 2000–2026, against a null of the same returns shuffled — which destroys serial structure and leaves the fat tails alone, so a peak that survives is structure and not kurtosis. Two hundred shuffles for the band.

In the returns, nothing stood up: no bin reached 1.2× the 99th percentile of the shuffled band, and about ten bins per instrument cleared it at all, which is what a thousand bins and a 99% band give you by chance. The bins that cleared repeated on no second instrument. Period estimates didn’t survive the move to the next window either — six instrument-estimator cells, all inside ±1.6 sd of shuffled.

The part I’d stress is the positive control, because it’s what stops this being a null from a blunt instrument. In absolute returns a peak stands up enormously — 24 bars at six to twenty-nine times the band on all three, and again at 98 on M15 and 293 on M5. That’s the trading day at each scale. Fed a real cycle, Welch and Burg find it and find it loudly. They just don’t find one in price.

Two honest limits. My A/B was a channel breakout whose only parameter is the lookback, chosen because a second free parameter lets either arm win by tuning rather than by adapting, so it says nothing directly about a band-pass tuned for mean reversion, which asks something different of the same estimate. And your result comes out of walk-forward optimisation, which is the right method; my worry is only that if the period itself isn’t persistent, walk-forward hides that rather than catching it.

Numbers and method are at https://turnmarks.com/filters/adaptive if useful. I’d be glad to be wrong about the premise: a shuffled-period arm on your ES setup would settle it faster than anything I ran.

What I like most is the focus on the core broker functions: login, asset data, price retrieval, and order execution. That is usually where most of the practical work is, especially when dealing with signatures, timestamps, JSON parsing, rate limits, and partial fills.

I have been looking at BYDFi’s API recently, and this kind of lean REST implementation is exactly the approach I prefer for testing small crypto strategies. Before automating anything serious, I think developers should first handle authentication properly, test read-only access, log every response, and make sure order execution behaves as expected in edge cases.

The main lesson is still the same: the trading logic may be simple, but API reliability and error handling decide whether the system is actually usable.

Yes, sorry. I’ve now uploaded it.

I am glad you mentioned our work. In case you are interested, I have written an article about the regime and how it worked this year , together with Python implementation (not 9 pages 😉 ).
https://fabiobaruffa.com/articles/market-regime-framework/

Thank you

Regarding Bob’s comments – thank you for posting! Well, I can only judge what I know – and that’s your evaluation process for Ranger, and your Rangermaker tool that you sent me for replicating the process. If you have another process, I don’t know it.
I can understand that you are defending your tool and process. I also understand that my objections against parts of them, and my improvement suggestions, have been unwelcome. After all, I’m no famous trader and my objections were just based on dry math. So let’s agree that we disagree here. The suggested improvements are done, in the form of our evaluation shell, and we both have a fine product. Let’s make the best of it.

– Bob, you can post links, but then your comment needs approval by an editor.