Why the desk stopped buying
Written on 4 September 2026, not on the day. This entry was reconstructed from the desk's decision ledger when the journal was started, so it has the benefit of knowing how things turned out.
The desk went quiet. Not broken quiet, where something throws and you get a stack trace. Quiet in the way that looks like caution: fewer buys, cash accumulating, every component reporting healthy. The scout was reading the news. The analysts were pitching. The manager was ruling on the pitches. It simply was not putting money to work at anything like its old rate.
Working out why took about an hour, and the investigation reversed its own conclusion twice before it landed. That is the part worth writing up, more than the answer.
The answer
On 31 July the scout's high-conviction rate fell off a cliff. It had been running between 34% and 40%. It spent one day at 12.5% and then settled between 2% and 6%, where it has stayed.
Nothing on our side changed. No scout code was committed in that window. Same prompt, same budget, same model name in the config, same everything. The model behind that name had been retrained, and the new one grades its own confidence far more strictly than the old one did. A vendor changed the meaning of a word we were sorting on, and told us by not telling us.
The desk did not stop buying because it had decided to be careful. It stopped buying because "high conviction" quietly started meaning something different.
Nothing had recorded it
This is the part that should worry anyone running a system like this. The event was invisible in three separate places at once.
The error log prunes at seven days, so anything provider-related from the period was already gone. The analysis table only records calls that succeeded, which means a provider incident does not show up as failures. It shows up as fewer rows, and fewer rows is indistinguishable from a quiet news week. And the working notes that might have caught it are gitignored, so they existed on exactly one machine and only ever logged our changes, never the world's.
Three logs, none of which could hold the shape of what happened.
So the desk got a decision ledger that day: an append-only file, in git, where any session that changes anything writes a row. Especially the changes git can never see, which is most of the ones that matter. Topping up a vendor account. Rotating a key. A knob flipped in a web interface on another machine. A provider changing behaviour under an unchanged model name, which is exactly this.
Everything else on this site is downstream of that file existing.
And then the answer turned out to be half right
Here is where it gets less satisfying, which is why it is worth telling.
The stricter bar looked like a clear improvement. Closed positions split at the break: before it, a 36% win rate and money lost. After it, 73% and money made. Buy rate down about a third. A tidy story about a stricter filter producing better trades, and the obvious conclusion was to leave the bar alone.
Then someone checked what else had shipped around that date.
Two weeks earlier the desk had started stamping an exit plan on every buy: a target, a horizon, and the condition that would prove the idea wrong. An intraday watcher went in the day after, to act on those plans without waiting for the daily review. That machinery took time to show up in the results, because a plan stamped on a trade in late July fires in the middle of August.
Which is to say it matures after the break, with a cause that predates it by ten days.
Measured across the same boundary: buys carrying a stamped plan went from 42% to 94%. Sells driven by a plan went from 2% to 28%, a fourteenfold rise as a share of exits. And the three largest realised gains after the break were all plan-driven exits, meaning trades that closed because a pre-committed rule fired, not trades that were selected by a stricter entry bar.
So there are two causes running concurrently across one boundary, and roughly fifteen closed positions to separate them with. They cannot be separated. Not with argument, and not with this sample.
What that leaves
Leaving the bar alone is still the right default, but the reason we would have given for it was wrong, or at least far more confident than the evidence supports. If most of the gain is the exit machinery rather than the entry filter, then the entry bar has more room than the first story implied, and someone acting on that first story would have been acting on a coincidence.
The honest position is: the desk behaves differently on either side of 31 July, we can date the boundary precisely, and we can only partly explain it. Both candidate explanations are written down, along with what would separate them, which needs more closed positions than exist yet.
If you have looked at the performance chart on this site and wondered why it starts at the beginning of August, this is why. The bot on either side of that line is not the same bot. What we cannot yet tell you is exactly which of the two things made it different.