The anatomy of a rules engine

Entries are overrated

Retail conversation about strategy is almost entirely about entries — which indicator, which pattern, which confluence. In a production system, entry logic is perhaps a tenth of the code and a smaller fraction of the outcome. The other nine tenths decide whether the system survives contact with a real broker.

The modules that actually matter

• —State management. What the system believes about open positions, and how it recovers that belief after a restart.
• —Risk allocator. Converts account equity and configuration into a lot size, with hard ceilings that no code path can exceed.
• —Order manager. Handles retries, partial fills, rejections and requotes without duplicating positions.
• —Guard rails. Spread limits, maximum exposure, news windows, daily loss cut-offs.
• —Telemetry. Structured logging of every decision, so post-mortems are possible without guessing.

Failure handling is the product

Markets are the easy adversary. The hard adversaries are dropped connections mid-order, a terminal restarting with positions already open, a broker rejecting a modification, and a symbol whose specification changed overnight. A system that only works when nothing goes wrong has not been engineered; it has been sketched.

The difference between a script and a system is what happens on the worst day, not the average one.

Determinism and auditability

Every decision should be reproducible from the log. Given the same inputs, the same state and the same configuration, the system must produce the same action — and you must be able to prove it after the fact. Non-deterministic behaviour is not a quirk, it is a defect that makes every future diagnosis a matter of opinion.

Configuration as a contract, not a playground

Every parameter you expose to a user is a decision you have delegated, and most delegated decisions in trading software are eventually used to increase risk under emotional pressure. A well-designed engine exposes intent — conservative, balanced, aggressive — and keeps the mechanics that could destroy an account behind constraints that no input can override.

Validate inputs at the boundary

• —Reject configurations that violate hard exposure ceilings rather than silently clamping them.
• —Log the effective configuration at startup so post-mortems know what was actually running.
• —Treat every externally supplied number as hostile until validated.
• —Version the configuration schema so old settings files fail loudly, not subtly.

Testing a system that talks to a live market

Unit tests for trading logic are necessary and nowhere near sufficient, because the interesting failures live in the interaction between your state machine and a broker that behaves unexpectedly. The technique that pays is simulating adversarial conditions: rejections, partial fills, duplicated confirmations, delayed acknowledgements and restarts at the worst possible instant.

The adversarial test suite

Test the day your broker misbehaves, because you will not get to choose when that day happens.