Building Rule-Based Automation

Chapter 10's pseudo-code made automation look like four lines. This chapter is about why production systems are four hundred — and why every line of the difference is a lesson someone learned expensively. You don't need to build all of this to benefit: knowing the 80% is how you evaluate any automation (yours, a vendor's, a friend's) like an engineer instead of a customer.

Principle 1 — The machine must always know its state. The deceptively hard question in automation isn't "when to buy" — it's "what do I currently hold?" Partial fills (Market Structure school: your order ate half a level), rejected orders, a restart mid-session, a manual intervention from your phone — each can desynchronize the code's belief about positions from the broker's reality. The classic blow-up: code believes it's flat, reality holds a position, logic fires again — doubled size, no stop. The professional pattern is humble and non-negotiable: never trust your own memory of state; reconcile against the broker's records (positions, orders) at every decision point, and halt on any mismatch. In pseudo-logic:

`` before any action: my_belief = internal_state broker_truth = fetch_positions_and_orders() if my_belief != broker_truth: halt_everything(); alert_human("STATE MISMATCH") ``

Those four lines prevent more disasters than any strategy improvement ever will.

Principle 2 — Every external call can fail; the code must pre-decide what then. Networks drop, APIs time out, rate limits trigger, exchanges reject (Chapter 1's checkpoints, now your responsibility to handle). Untrained code meeting an error does one of two catastrophic things: crashes silently (strategy stops, positions orphaned, nobody knows) or retries blindly (the 400-duplicate-orders story — a timeout on a successful order, retried in a loop). The discipline: every action has a written failure path — if the entry order errors, do we retry once, or skip the signal? if the STOP order fails after the entry filled (the nightmare case) — alert immediately and flatten? Note what this is: Kovner's rule recursively applied — the exit plan for the trade, and the exit plan for the system placing the trade.

Principle 3 — The kill switch is the first feature, not the last. Before any strategy logic exists, build the off-switches, in layers: a manual halt you can trigger from your phone in seconds (not by finding a laptop and killing a process); automatic circuit breakers — daily loss limit hit → flatten and stop; order count exceeds sanity threshold → halt; state mismatch → halt (Principle 1); heartbeat lost → assume the worst. Your Market Structure school taught that exchanges run circuit breakers because speed amplifies error faster than humans react; your automation is a tiny exchange, and it needs the same physics respected. And one layer deeper: your broker's RMS (Chapter 1) is the final backstop — know your account-level limits and consider setting them deliberately tight for the automated segment (the hard-walled jar from the Behavioural Finance school, implemented as account architecture).

Principle 4 — Supervised autonomy: logs, dashboards, and the human on the loop. The retail-appropriate model is not "set and forget" — it's supervised autonomy: the machine executes, the human monitors on the loop (reviewing, able to intervene) rather than in it (approving every action) or off it (absent). Minimum viable supervision: every decision and action logged with timestamps and reasons (the system's own QbarTrade — when something weird happens, the log is the only witness); a heartbeat (the system proves it's alive on schedule — silence itself triggers alerts); and notifications on actions (every entry/exit pinged to your clean alert channel from Chapter 6 — you should never discover a position). Then the same graduation pipeline as Chapter 9, because automation is just another operator: paper mode → token size live → scale on evidence — with the machine's operational metrics (state mismatches, error rates, slippage vs. assumptions) reviewed as seriously as its P&L.

Principle 5 — Simplicity is a safety feature. Every component you add — another data source, another instrument, another clever adjustment — multiplies failure modes combinatorially. The engineering culture your Jane-Street-influenced Qbar architecture already knows applies doubly here: boring, readable, single-strategy systems with obvious failure paths outlive sophisticated ones. In automation, clever is a cost center.