Engineering note · Strategy requirements
Write the Trading Rules Before the EA
A trading idea can sound precise until two developers translate it into different orders. One reads “breakout” at the first tick above a level. Another waits for the bar to close. Both can show a plausible chart. Before requesting an EA build, write the inputs and expected decision so the same case has only one permitted result.
- 01Freeze the inputs
- 02Write one decision rule
- 03Name the failure state
- 04Run three acceptance cases
Start with the decision, not the indicator name
For each entry, identify the platform and version, symbol, timeframe, session, time zone, price feed and exact event that makes the rule eligible. Say whether the EA reads a forming bar, the last closed bar or a sequence of closed bars. If it needs a higher timeframe, specify which completed higher-timeframe value is available at the decision time. A visual marker drawn later is not a substitute for this timing rule.
Write the direction, threshold and comparison operator. “Above” could mean strictly greater than or greater than or equal to. State what happens when the price equals the level, when the spread widens and when two signals appear on one bar. If an entry is allowed only once per setup, define the setup identity and the event that resets it. Those details turn a sentence into a testable decision.
Keep filters in a declared order. A signal may qualify but fail a session, spread or exposure filter. The log should name the first rejected condition, not merely say no trade. This makes a missing order explainable without changing the strategy until a chart looks right. For an existing EA, preserve the current behavior as a baseline before revising one rule.
- Input: exact candle and account state at the decision time.
- Rule: one named trigger, filters and precedence.
- Decision: enter, exit, hold or reject with a reason.
- Evidence: the values read and the resulting action or terminal state.
Make exit and sizing rules just as exact
An entry rule does not describe what happens next. Define the stop and target as prices or explicit calculations from frozen inputs. Say when they are placed, whether they can move, and what a manual close or partial fill does to the remaining position. If a reversal is allowed, describe the old position, pending orders and protection before submitting a new side. The implementation must not infer this from a screenshot.
Sizing needs a named account basis and units. State whether the budget comes from a fixed cash amount, balance or equity, when that value is sampled, how the stop distance becomes requested volume, and how the broker minimum, maximum and increment are handled. If the smallest legal volume would exceed the agreed budget, the specification needs an explicit skip or rejection outcome. An order call alone does not prove the requested position exists.
List the permitted state transitions. A decision to submit, a platform return code, an accepted order and an actual position are separate observations. A rejected or uncertain order needs a terminal reason or a reconciliation step. Do not use a blind retry to make a test green. The specification should say what is recorded and what new evidence permits another attempt.
Freeze a small fixture before comparing implementations
A fixture is a small, reviewable bundle of inputs and expected outputs. Record the source candle with time, open, high, low and close, the relevant earlier bars, symbol properties, account values and starting orders or positions. Keep the same feed and timestamp convention across reruns. If a broker feed or server clock changes, label that difference rather than attributing every changed decision to the EA code.
Use a decision table with columns for starting state, trigger, filter values, expected side, requested size and expected state after processing. Include a no-action row. This exposes branches that prose often hides, such as a signal that qualifies while the spread limit blocks entry. A developer can replay the fixture without guessing what a chart annotation meant.
Keep the authorized source revision and input set beside the fixture. If the rule changes, make a second fixture version and show the one changed statement and the resulting decision difference. Do not silently overwrite the old expected result. A useful revision says which branch changed, which tests remain the same and which new case is needed.
Use acceptance to close a bounded build
The three checks below are a starting contract, not evidence that a system has passed. Run them with the agreed platform, version, data source and test environment. Retain input files, logs and the source revision used for the run. Record a pass or a fail for each expected decision. If one case fails, keep the failure trace; do not replace the case with an easier period.
A specification also names exclusions. It can prove that a coded decision follows frozen rules for selected cases. It does not prove that those rules are profitable, that historical fills match future execution or that a broker will accept every order. Market data gaps, slippage, account permissions and platform limits remain separate boundaries. State which of those are tested and which are only assumptions.
Before requesting a quote, provide the rule sheet, authorized source if one exists, the three fixtures and the desired delivery evidence. That lets the scope name one result and a clear acceptance boundary. If the rule sheet still contains competing interpretations, resolve them before implementation. More code cannot decide which trading rule the owner intended.
Three acceptance checks
Proposed tests, not executed customer results. Record actual outcomes separately.
Same inputs, same decision
Input: Run the same candle, prior-bar sequence, symbol properties, account values and starting position twice under the frozen source and inputs.
Expected: Both runs return the same entry, exit and size decisions with the same reason codes. Any stateful difference is identified rather than hidden.
Explicit failure outcome
Input: Feed one missing-price case, one spread-limit breach and one rejected order through the declared branches.
Expected: Each case records one explicit terminal or reconciliation outcome. No case becomes a filled position or triggers a blind retry without confirming the actual state.
One declared rule change
Input: Change exactly one rule in a new specification version and rerun the original fixture and the affected case.
Expected: Show the rule diff, fixture diff and resulting decision diff. Unaffected decisions remain the same; a changed decision has one named cause.
Sources and related guides
Start with your own rules
Write down the rule and its missing decisions before asking for an EA quote. The free Rule Check is the first step; it does not require an account or payment.
Run the free Rule Check →