Write a Strategy Rulebook Before Coding an Algo
Turn a trading idea into explicit entry, exit, sizing and failure rules that can be reviewed and tested.
Translate the idea into observable conditions
A rulebook begins by replacing subjective phrases with conditions that another person could evaluate the same way. Define the instrument universe, data interval, market session and exact values used by each signal. Explain whether a bar must close before the rule is checked and how missing or delayed data is handled. State whether multiple signals can occur on the same instrument and which one takes priority. Avoid wording such as ‘strong trend’ unless it is backed by a measurable definition. This exercise often reveals gaps before code exists. It also creates a shared reference for a developer, reviewer and operator, reducing misunderstandings during implementation.
Specify entries, exits and position management
For every entry, document the trigger, permitted order type, quantity calculation and conditions that cancel the signal. Define exits independently: target, stop, time-based close, reversal, session end or manual intervention. Explain how partial fills, rejected orders and position changes affect the next decision. If a position can be scaled or hedged, specify the state transitions and maximum exposure. Include behavior for duplicate signals and for a strategy restart when positions already exist. A clear rulebook distinguishes a trade intention from confirmed broker exposure. It should be possible to map each clause to a test case and a visible system action.
Include costs, boundaries and risk controls
State assumptions for commissions, exchange charges, taxes, spread, slippage and order latency used in research. List hard boundaries such as maximum quantity, restricted instruments, trading hours and loss-triggered pauses. Explain what the system should do during an API outage, stale market feed, token expiry or ambiguous order response. Use conservative assumptions and acknowledge that live fills can differ from a simulation. Risk settings should be chosen for the actual user and account rather than copied from a generic article. A strategy without a failure plan is not complete, even if its historical entry and exit chart looks attractive.
Use the rulebook for review and maintenance
Version the document alongside code and tests, and record why a rule changes. Validate a new version against data not used to design it, then test its behavior in a safe environment where available. After any broker or platform change, recheck the rules most affected by order handling and data timing. Keep a log of exceptions and manual actions, and update the rulebook when the intended process changes. Do not interpret a backtest as proof of future performance. A precise specification improves communication and testability; it does not remove market risk or ensure that the strategy will make money.