The risk boundary you consider obvious does not exist unless you define it in the trading system. An automated bot follows written conditions, so an unconfigured overnight exposure limit, stop, or position cap cannot protect you.
In 1996, the first Ariane 5 rocket lifted off from Kourou, French Guiana. About 37 seconds into the flight, its guidance system failed. The rocket veered off course and destroyed itself.
The European Space Agency’s inquiry traced the failure to software inherited from Ariane 4. A 64-bit floating-point value representing horizontal velocity was converted into a 16-bit signed integer. The Ariane 5 flight produced a value outside the range the software could handle. The conversion triggered an exception, the backup system failed for the same reason, and diagnostic data was interpreted as flight data.
The software performed according to assumptions written for another rocket. Reality exceeded those assumptions.
Your bot cannot infer the bedside rule
Picture the phone screen beside your bed. You wake, check the account, and find a live position larger than expected. The bot entered while you slept because its conditions were met.
You believed it would never open that much exposure overnight. Perhaps you had said the rule aloud. Perhaps it appeared in your notes: no new position after midnight, no overnight exposure above 2% of the account, no trade without a defined exit.
None of that matters to software unless the rule exists as a configured, testable condition.
Automated trading bots fail in ways that often look irrational to the person using them. The machine may have followed its instructions exactly. The missing instruction was the problem.
This is the connection to Ariane 5: both systems operated inside boundaries their users assumed were safe. Neither system could stop and ask whether the inherited assumptions still made sense under current conditions.
Translate judgment into explicit constraints
“Keep risk reasonable” cannot be executed. Neither can “avoid bad overnight trades.”
A usable boundary needs values and a defined response. For example:
- Reject a proposed trade when total open risk would exceed the account limit.
- Require every queued signal to include an entry, invalidation level, and position size.
- Block new entries during hours you have chosen not to supervise.
- Reject any order whose size exceeds a fixed percentage of account equity.
- Pause new signals after a specified daily or weekly loss threshold.
The exact values depend on the trader, account, market, and method. A trader with a $700 account and someone managing $80,000 should not copy the same position size. Both need a rule they can inspect before an order exists.
If you have not defined that number, start with the arithmetic in how much should I risk per trade. Treat every figure as an illustration, then decide what boundary fits your own loss tolerance.
Run the same exercise for conditions beyond position size. Ask what must be true before entry, what cancels the setup, how correlated positions count toward total exposure, and what happens when market data is incomplete. Write each answer so another person could determine whether a proposed trade passes or fails.
Put approval between the signal and the order
A hard risk rule catches known failure modes. Human approval catches context the rules do not yet contain.
Nokware generates and queues trade signals for review. You approve or reject each one before execution. That pause makes the hidden assumption visible while there is still time to challenge it.
The approval decision should be concrete:
- Does the proposed size stay inside the risk limit?
- Is the invalidation level present and plausible?
- What would total exposure become after approval?
- Would this position remain acceptable if you could not check it for several hours?
- Which written rule permits the trade?
A queue also creates a record of restraint. Rejected signals matter because they show which boundaries prevented exposure. The review of 30 days of queued signals shows the value of recording both sides of that decision.
An approval gate does add friction. That friction is useful when a model proposes placing real money at risk. It forces the trader to confirm that the order matches the plan before consequences make the disagreement obvious.
Test the assumptions before bedtime
The Ariane 5 inquiry did not find a mysterious intelligence making an inexplicable choice. It found reused logic, an unhandled value, and two systems carrying the same assumption.
Review your trading setup with the same discipline. List every sentence beginning with “the bot would never.” Then locate the exact rule that prevents it.
If you cannot point to the condition, limit, or approval step, treat the boundary as absent. Configure it, test it with values on both sides of the limit, and verify that the system rejects the failing case.
Before the next overnight session, inspect one proposed order from entry through position sizing and exit. Do not ask whether the bot seems sensible. Ask what it is explicitly allowed to do.
Educational content, not financial advice.
Comments
No comments yet.