TOS-BOT: a production trading system, run like a regulated release process

The platform watches a rotating pool of US equities through the pre-market and opening session, evaluates entry and exit conditions once per second against live and reconstructed bars, and routes the resulting orders to a broker. It runs unattended from before 04:00 ET, supervises itself, records everything it saw, and reconciles against the broker's own record at the end of the day.

Several strategy variants run side by side. Some trade real capital. Others run in shadow mode on the same live feed, taking no positions, so a candidate can be measured against production conditions for weeks before anyone argues for promoting it.

One screen decides whether the day proceeds. Per-engine attribution across each session window sits at the top, the ranked candidate universe on the left, and one card per active slot showing what every engine currently thinks about that symbol. A single entry and exit is running through it below; the trade lands in the blotter underneath as it closes.

The single design decision I would defend hardest is the split below. Orders leave on a send-only webhook. Everything that reads account state — the watchdog's ground truth, the operator panel, the end-of-day reconciliation — comes back over a separate, credential-scoped read-only API that has no order endpoint at all.

The result is that the component most likely to have a bug under stress, the supervisor deciding whether to intervene, is reading from a path that cannot itself cause a trade.

None of these were designed up front. Each is the permanent residue of something that went wrong once, in production, with money on it.

The live code tree is immutable while running. Every change ships as a dated package that states exactly which files it touches, installs itself, and can revert itself. Thirty-five such packages exist, each one a permanent record of what changed and why.

Before a package is accepted, the entire tree is hashed and compared file by file against the running baseline. The deploy note has to show the expected modification count and nothing else. Then the revert is run and the tree is hashed again, and it has to come back byte-identical. A change that cannot prove it undoes itself does not ship.

Nothing reaches the live system on the strength of a backtest alone. The research platform reconstructs each candidate trade from one-second bars and then asks two independent questions about it, from two sources that do not share a failure mode:

Recorder files are named for the session they were opened in, not the session they contain, and several open the evening before. Indexing by filename produced a fake 62% "the system never saw it" rate that was entirely an artefact. Files are now indexed by the real time span of their contents.

Separately, the reconstruction's exits resolve against bar wicks, which is the optimistic end of the range. That is stated on every result the rig produces rather than discovered later by whoever reads it.

The research backlog ran to roughly twenty candidate changes. The majority were killed. Two examples are worth stating plainly, because they are the reason I trust the remaining ones at all.

Effectively all of the implementation was produced with an AI coding agent. I did not write most of these 381 modules by hand, and I would not claim otherwise. What I did own is the part that makes the output usable: the specification, the acceptance criteria, the verification, and the decision to ship or not.

That division is the whole reason the change-control machinery above exists. An agent that can produce a working feature in an hour can also produce a plausible-looking one that quietly breaks a dependency three files away. Hash-proofed additive packages, observe-mode rollout, install-order audits and a pre-session QC harness are not bureaucracy — they are the control surface that makes fast AI-generated change safe to put in front of real capital.