Rule-Parity: The Fastest Way to Automate a Manual Strategy

Most trading strategy automation projects fail. Not because the code is bad, but because the rules were never properly defined. A trader says "I buy when price breaks out above resistance with volume confirmation" — but what counts as a breakout? How many ticks above? What volume threshold? What happens on a gap open? The ambiguity compounds until the developer's interpretation and the trader's intent have quietly diverged.

What is rule-parity?

Rule-parity means the automated strategy executes trades under exactly the same conditions as the trader would manually — no more, no less. It's the measurable point where, given identical market data, the bot and the human would make the same decisions. Achieving this requires converting intuition into explicit, testable rules and then verifying them trade by trade.

Why automation projects fail without it

• •Ambiguous rules: "Buy on support" means different things to the trader and the developer. Without a written spec, both assume they agree — until the backtest looks wrong.
• •No feedback mechanism: The trader sees a backtest equity curve and says "looks wrong" but can't point to a specific trade. Without per-trade audit logs, debugging is guesswork.
• •Scope creep: Without a signed-off spec, new rules get added mid-build. Each change invalidates previous testing. The project never converges.
• •Overfitting during development: To make the backtest "look right," parameters get tweaked to match the trader's memory of past trades. The strategy is now fitted to history, not to rules.
• •No deployment confidence: Even if the backtest looks good, the trader doesn't trust it because they can't verify how individual trades were decided.

The rule-parity process

The process works in five stages. First, intake: the trader provides whatever they have — screenshots, chat logs, PDFs, screen recordings. Second, specification: we convert those inputs into a structured document covering entries, exits, filters, position sizing, edge cases, and test cases. The trader signs off before any code is written.

Third, instrumented build: the strategy is coded with logging that records exactly which rules triggered for every bar and why trades were taken or skipped. Fourth, trade audit: we generate reports showing each trade alongside the rule that triggered it, the data that was used, and the risk constraints that applied. The trader reviews specific moments on the chart and annotates exceptions.

Fifth, the screenshot feedback loop: if a trade doesn't match expectations, we trace it back to the spec. Either the spec was incomplete (we update it) or the code has a bug (we fix it). We iterate until rule-parity is achieved — meaning every trade can be explained by a rule in the spec, and no rule in the spec is missing from the code.

What rule-parity looks like in practice

For an MT5 Expert Advisor, rule-parity means the EA's trade log matches the trader's manual review of the same chart period. For a Pine Script strategy, it means the strategy's entry/exit markers on the chart match exactly where the trader would have acted. The key is that every trade has a traceable reason, and every rule has been tested against known scenarios.

Key takeaways

• •Write the spec before the code. Ambiguity is the root cause of most failed automation projects.
• •Log every decision, not just every trade. You need to know why the bot didn't trade as much as why it did.
• •Iterate on the spec, not the parameters. If a trade looks wrong, check the rules first — not the backtest settings.
• •Rule-parity is a milestone, not a feature. Once achieved, you can move on to optimisation with confidence that you're improving a correct strategy, not masking a broken one.