Preventing an incorrect order and establishing a strategy worth funding turned out to be different jobs. While developing a Korean stock bot, I added controls for order failures and conditions that could block new purchases. Those controls did not establish profitability. On 15 July 2026, I instructed the live-account bot to stop while paper operation continued.
AI assisted with implementation; I directed the separation of live trading from validation and made the stop decision. This is an account of that design and decision, not a claim of verified excess return from short backtests or internal checks.
Keeping experiments away from the live path
The system separated live orders, paper operation without real-money orders, and a Lab for testing new strategies. A promising historical backtest was therefore not, by itself, a reason to change the live configuration.
I also separated two questions about moving forward. Was the order and balance-handling path ready for a limited operational trial? And had the strategy accumulated enough observation and comparison to justify confidence in it? Completing the first kind of trial would not answer the second question.
Deciding what happens after an order fails
The order path included a guard that checked the day’s failure records and a manual stop signal before allowing new purchases. Per-instrument rejection records distinguished continuing restrictions from temporary failures counted within a day, so an unchanged rejection would not simply trigger repeated attempts. The buy-side guard did not also block selling or closing positions.
Another check compared instruments reported by the broker with those in the bot’s internal tracker. An instrument present on only one side could reveal a missing tracking entry or a position left in the internal record. This was not a full reconciliation of every position quantity. Some failed or empty queries skipped comparison, so the code cannot be described as stopping orders safely under every fault.
An implemented guard and a guard validated under actual failures are different levels of assurance. Neither would establish that the trading strategy was profitable.
A monitoring number still needs its inputs
A separate gauge summarized the span of stored portfolio observations and maximum drawdown, together with a profit factor from closed trades and a market benchmark over the same dates. Maximum drawdown measures the fall from a previous portfolio peak. Profit factor compares total gains from winning trades with total losses from losing trades. Both depend on the observation window and the underlying trade record.
If benchmark prices were unavailable, the code left excess return unknown instead of filling it with zero. It also reported profit factor as unavailable when there was insufficient closed-trade information. The presence of these checks in a gauge did not mean that every later validation requirement in the design was automatically enforced by code.
What stopped on 15 July
My instruction stopped the live-account bot and explicitly retained paper operation. The subsequent status responses showed the live service inactive and disabled for automatic startup. That is a dated stop of the live path, not evidence that all experimentation ended or that the entire server is off today.
I kept the defensive code and the validation structure, but did not let the existence of those components make the operating decision for me. At this stage, I stopped the path handling real money and kept simulated observation separate.