The engine kept shorting into breakouts. The public record caught it.
We publish every call our engine makes — timestamped, append-only, never edited, including the losers. This is the story of how that record diagnosed a real flaw, and the one-rule fix that removed only losing trades.
The row that looked wrong
On July 9 our own public track record showed a row like this:
Meanwhile the short-term book — a simple 20-day breakout system we log side by side with the careful engine — was pointing the other way on the same coin: price had just closed above its prior 20-day high. One engine said short. The other said the market is breaking out upward.
Scroll back through the losing shorts of the previous two weeks and the same fingerprint kept showing up: the shorts that lost were disproportionately the ones fired while price was breaking out the other way. The confirmed-downtrend logic was right about the long-term trend and still got run over by short-term strength — the classic post-rally squeeze.
Testing it honestly
A pattern you notice in hindsight is a hypothesis, not a fix. So we replayed the engine's full logged tick history — tens of thousands of server-side engine ticks, using only data the engine had at each moment — with one added rule: a confirmed short is vetoed to cash whenever the 20-day breakout points up.
hit rate: 55% → 56% (barely moves)
net return: +83% → +91% on the replay window
Two things made this rule shippable where other ideas weren't. First, it only removed losing trades on the record — it never blocked a winner. Second, and more important: the rule is sound independent of the backtest. "Don't short into a confirmed breakout" is a principle a trader would defend with zero data. We're not fitting noise; we're encoding discipline the record showed we lacked.
We also tested a looser version — veto whenever price is simply above its 20-day average — and it was net-neutral. Rejected. If a rule doesn't clearly earn its place, it doesn't ship.
What we didn't ship
The same review tested several tempting "improvements" that all failed replay: re-entry spacing (worse at every setting), a 24-hour persistence requirement (marginal), volatility-scaled stops (kills the net), and a chop-quality filter (cut net return from +83% to +55%). All rejected. The graveyard matters as much as the fix — most ideas that sound smart lose money, and the only way to know is to replay them against a record you can't edit.
Why we work this way
Every quant tool claims its engine works. Almost none publish the calls that didn't. Our bet is the opposite: an append-only public record — server-timestamped, never edited — is worth more than any marketing number, because it's the only thing a skeptic can verify alone. And as this episode shows, it's not just marketing honesty: the record is the diagnostic instrument. It caught our re-entry problem in July (v2.2's 48-hour cooldown came from the same kind of audit), and now it caught the breakout shorts.
Win rate barely moved, and we don't care. A disciplined system can win barely half its trades and still compound, because winners run and losers are cut. The number that matters is the net result of taking every call — and that's the number the veto improved.
Judge the engine yourself
The full record — every call, both books, wins and losses, never edited — is public. No login, no card.
See the track record →Quant Terminal is research and educational software — not financial advice, and not a recommendation to buy or sell anything. Replay/backtest figures are historical simulations on logged data ("backtested"), not live returns, and past performance does not predict future results. Crypto is extremely volatile and you can lose your entire investment.