The right answer, printed to nobody
A cash-management script computed the correct action on every single run — as a printout, with nothing wired to read it. ₹3,677 of tradeable cash, a ₹30,000 buffer, and a perfectly idle recommendation.
Two policies in my execution system were both correct, and together they nearly cost me a position.
Policy one: idle cash gets parked in a liquid ETF. Right call — un-deployed cash earning nothing is a leak, and the park is a day away from being spendable.
Policy two: the order runner fires approved buys at their scheduled time. Also right.
The collision: liquid-fund redemptions settle T+1. Park aggressively and your raw, spendable-today cash runs thin. One morning a buy fired into a balance the park had hollowed out, the broker bounced it for insufficient funds, and under my no-blind-retry rule a bounced order is terminal. The parking policy had killed the exact buy the cash was being kept warm for. Neither policy was wrong. They had never been introduced to each other — the runner had no funds check at all; it fired every approved buy blind and let the broker be the one to say no.
It got better. A fill later that week left raw cash at ₹3,677 against a ₹30,000 working buffer. The cash-park script, dutifully running on schedule, printed the correct remedy — UNPARK: SELL 229 units — on every single run. To nobody. It was built to emit a recommendation, and no process, human or machine, had ever been wired to consume it. The system contained the diagnosis and the cure and no nervous system connecting them.
What got built
A funding rail. Before placing any buy, the runner reads the live cash balance and compares it against the order’s cost plus a buffer for charges — brokerage, transaction taxes, the lot. If cash is short, the order is neither fired nor dropped: it flips to a waiting-for-funds state, its expiry rolls forward, and the runner queues the liquid-fund redemption sized to close the gap. Proceeds land tomorrow; the buy fires next session at a fresh price, still capped at its original thesis ceiling. Deferral is bounded — after three sessions it escalates to a human rather than deferring silently forever.
Two asymmetries are deliberate. Sells are never funding-gated — a sell raises cash, and gating an exit behind a cash check would be exactly backwards. And if the balance cannot be read, the rail stands down and places as before — an unreadable number is an unknown, not a zero, and freezing the book on a transient API failure is a worse failure than the one being prevented.
A buffer restore. The rail above is reactive — it costs a session every time it trips. So at the end of every run, the runner tops raw cash back up to a standing buffer, sized to fund one full position immediately. The subtle clause: this check runs including on runs that place nothing — because a buffer is emptied by fills, and the run after a fill is precisely the one with no orders left to place. Skip the idle runs and the restore never fires when it matters.
The lesson I actually keep
Printing the right answer is not an action. Every “recommendation” a system emits should be able to name its consumer — the process or person who acts on it, and what happens if they don’t. If the consumer is “whoever happens to read the logs,” the honest description is that the system has an opinion, not a control.
The finance version is older than software: an exception report nobody is assigned to clear is indistinguishable from no report at all.