Trading strategy documentation: a 30-day implementation plan

A sentence leaves out the machinery

"Buy a breakout and exit when momentum fades" sounds clear until software has to decide which price counts as the breakout, when the signal becomes valid, and what to do with an order that only partly fills. A human may resolve those questions from context. An unattended agent cannot safely rely on context it has never been given.

Take a more specific example: buy when a share closes above its 20-day high on volume above 1.5 times its 20-day average, risk 0.25 per cent of account equity, and exit below the 10-day low. It still leaves material choices open.

Does the 20-day high include today's bar? Is volume adjusted for a split? Is risk measured from the stop price or the entry price? Does the signal use the official close, the last trade, or a delayed bar?

Those choices can change trades, not just code style. A signal calculated from a bar before it is complete can introduce look-ahead.

A stop based on a closing price may behave differently from a stop order resting at the venue. A strategy that assumes a full fill can report a position that the broker never assigned.

For a trading agent, strategy documentation has to describe both the decision and its operating conditions. The aim is not to make the prose longer. It is to make every consequential interpretation visible, testable and versioned.

Turn the prose into a contract

Write each rule as an input, a calculation, a decision and an action. Define the instrument universe and trading calendar, then specify the data fields, adjustment policy, bar frequency and timestamp convention. State the signal formula precisely enough that two independent implementations produce the same result from the same input data.

For sizing, define the equity snapshot, risk budget, stop distance, share rounding and maximum notional. If the intended risk is 0.25 per cent of equity, say whether equity means prior-day net liquidation value or current marked value. State how the system handles a stop distance of zero, a quantity below the broker's minimum, or a position already at its cap.

Separate signal rules from order rules. A signal can say "target 100 shares"; the order policy must say whether to submit a market order, a limit order with a price collar, or several child orders.

It should also set a time-in-force, a cancel condition, a retry policy and a treatment for partial fills. One useful contract contains:

• Data definitions, including time zone, missing-bar treatment and corporate-action adjustments.
• Signal and sizing equations, with boundary conditions and rounding rules.
• Order state transitions, including rejects, cancels, partial fills and duplicate events.
• Risk limits, such as maximum position, daily loss and stale-data shutdown thresholds.

Keep these rules in a machine-readable configuration where practical, with a human-readable explanation beside them. A reviewer should be able to trace a live order back to the exact rule and data version that produced it.

Days 1 to 5: settle data meaning

Start with one instrument, one bar frequency and one order type. Do not begin by supporting every market the eventual system might trade. Narrow scope makes disagreements about meaning easier to find, and it gives the team a repeatable reference case.

Use the first five days to settle data semantics. Record whether timestamps mark bar open or close, which time zone applies, how daylight-saving changes are handled, and whether extended-hours trades enter indicators.

Choose adjusted or unadjusted prices deliberately. Dividends and splits can alter historical values, while a live feed may provide raw prices. Mixing those series can create false signals or incorrect stops.

Define what happens when a bar is late, absent or revised. For example, the agent might reject a signal if the latest required bar is more than two expected intervals old.

Specify whether a missing volume value invalidates the signal or is imputed. Imputation should be explicit, because silently filling missing values can make a data outage look like a valid market observation.

Build a small set of golden input cases: a normal session, an early close, a daylight-saving transition, a split and a missing bar. For each case, store expected indicator values and decisions. This catches mismatches between backtest code and live data adapters before order routing enters the picture.

Days 6 to 15: implement and replay

Implement the rules in separate components: data validation, signal calculation, portfolio sizing, order construction and broker-state reconciliation. Keep the strategy from assuming that a requested order equals an executed position. The broker's execution reports and position snapshots are authoritative for what filled; the strategy's target is only an intention.

Replay historical events through the same decision and order-state code that will run in production. Include rejected orders, delayed acknowledgements, duplicate execution reports, partial fills and cancel-replace sequences. A replay that feeds only clean bars into a signal function does not test an order-placing agent.

Use plausible cost assumptions, then vary them rather than treating one backtest figure as truth. The following are typical market ranges for liquid US equities, not audited results or a quote for a particular account. Actual costs depend on the instrument, order size, venue, broker and market conditions.

Track decision-to-submit latency, acknowledgement latency, fill ratio, reject rate and slippage against the decision price. Compare those measures by order type and session. Typical API and venue delays vary widely, so measure the actual path rather than assuming that a fast response from a development machine predicts production behaviour.

Days 16 to 30: test the live boundary

Use the final two weeks to exercise the complete workflow without risking capital. Paper trading is useful for checking signal timing, order-state transitions and monitoring, but it may not reproduce queue priority, market impact or every broker rejection. A paper environment such as agentic paper trading from FX-Tech, with plans from $9.99 a month, can provide a place to exercise agent workflows. Treat its fills as test evidence, not proof of live execution quality.

Run the agent against live market data in shadow mode first. It should calculate intended orders and log them without transmitting them. Compare each decision with the written contract, inspect time stamps and verify that no stale or malformed data passed the gates. Then route paper orders and reconcile the agent's order ledger against the simulator's reported positions.

Use this checklist before considering any live order:

1. Confirm that data age, time zone, adjustment policy and session calendar match the contract.
2. Replay a gap, a halt, a missing bar and a corporate action with expected results stored.
3. Verify that duplicate events cannot create duplicate exposure, and that retries use stable order identifiers where supported.
4. Test partial fills, rejected orders, cancel requests and broker disconnect recovery.
5. Set hard limits for order notional, position size, daily loss and maximum open orders.
6. Prove that a kill switch cancels working orders where possible and blocks new submissions.
7. Check that alerts reach an operator and that logs preserve inputs, decisions, requests and broker responses.

Keep the first live scope deliberately small: one instrument, a low notional cap and a defined trading window. Require an operator to review the first sessions, even if normal operation is intended to be unattended. Set a rollback condition in advance, such as a reconciliation mismatch, an unexpected reject burst or a data feed exceeding its age limit.

Keep the translation attached to production

Strategy rules change. A revised lookback, new universe filter or altered stop calculation can change risk even if the change is described as minor. Store the strategy contract, code version, data schema and deployment configuration together. Each order should be traceable to a strategy version and decision record.

Monitor both trading outcomes and system behaviour. Useful operational measures include stale-data events, orders without acknowledgements, time to reconcile positions, unexplained cash differences, rejected-order causes and divergence between target and actual exposure. Alert on thresholds that require action, not every routine log line. For example, a position mismatch should block new exposure until reconciled, rather than merely creating a dashboard warning.

Review cost assumptions against observed fills on a regular schedule, but keep market impact estimates cautious when sample sizes are small. A few fills cannot establish a stable slippage distribution.

Record the sample count and market conditions alongside any changed assumption. If execution costs rise, the system should be able to reduce size or stop trading under a specified rule, not rely on someone noticing a backtest has become stale.

If this were my operation, I would first write the contract for one instrument and one order type, then replay a week containing a gap, a halt and a partial fill. I would not enable live routing until the position and cash ledger reconciled after every event.

#agentic trading #paper trading #automated trading rules #strategy to code #trading system specification #order execution logic #trading data semantics #algorithmic trading risk