Two runs of the same robot can produce different results while the visible parameters remain unchanged. Before modifying the strategy, establish whether the code, data, symbol specification and execution model also match. A run manifest records these conditions. The comparator below checks two declarations, and a worked example isolates a commission change. Identical records still do not prove identical environments, so keep the reports and execution logs behind each record.

What should you preserve before running the tester again?

Keep both reports, execution lists, journals and parameter sets. Label them as separate runs, including the less favourable result. A screenshot of the equity curve cannot establish the first fill price, partial execution count or actual test start. You need a trail from the run conditions to the operations, then to the final result.

Distinguish a single test from an optimisation search and an evaluation on a later period. These modes are described in Strategy Tester documentation. “The same robot” might mean the same filename but a different compilation or dependency. Preserve the terminal build, program and relevant libraries. A filename does not identify its contents.

Compare the requested start with the actual start. MetaQuotes explains that insufficient preparation history can shift the beginning of a test. A full month and a shortened period are different evaluations. Our CSV coverage checker inspects the export itself; this guide checks a broader set of run conditions.

How do you prepare two manifests in the same format?

Paste two JSON objects using exactly the thirteen field names in the table. Do not translate the keys or add your own top-level fields. version is the number 1: it identifies the manifest format, not the EA version. Other values are strings. inputs, costs and initialState may instead contain plain objects describing their settings.

Manifest fields: what are you comparing?
Field namesWhat to record
version, platform, build, codeRevisionFormat, platform, build, and code/dependency identification.
inputs, dataSnapshotInput parameters and the preserved dataset version.
symbolSpecification, executionModel, costsContract specification, simulation rules and all assumed costs.
requestedStart, actualStart, endRequested and actual boundaries of the evaluation.
initialStateStarting balance, positions and relevant initialization conditions.

For dataSnapshot, enter an archive identifier or a checksum you calculated separately. “data-v1” remains a declaration: the page does not inspect its file. Likewise, calling codeRevision a hash does not verify it. Technical version labels are sufficient; do not include passwords, access codes or personal details.

Use dates with explicit time zones, preferably a consistent UTC representation. The comparator checks written records, not the provider’s calendar. Different descriptions of the same instant may require manual standardisation. Adding Z to a server time does not convert it to UTC. Mark an unknown value as information to establish rather than inventing an identifier that appears authoritative.

What does the run comparator actually check?

The tool provides two example records to edit and compares their fields. It works locally without sending data, importing files or saving entries persistently. Review differences and missing declarations. It neither runs MT5 nor reads an account, and it cannot verify that the descriptions match the actual tests. Equal objects mean equal entries; they do not establish identical market conditions or a completely specified environment.

Compare two backtest records

Analysis runs locally in your browser. The tool neither sends data nor saves it persistently. Do not enter passwords or personal details.

Use the documented schema with version: 1. Record specification numbers as decimal-point strings. Empty or missing fields mean unknown. Each record is limited to 64 KiB.

JSON format: fields and limits

version: 1. Other supported fields: platform, build, codeRevision, inputs, dataSnapshot, symbolSpecification, executionModel, costs, requestedStart, actualStart, end, initialState.

Top-level field values are strings. inputs, costs and initialState may also be objects. Empty or omitted fields are treated as unknown. Duplicate keys and undocumented top-level fields are rejected. Limits: 8 levels and 2,000 values; nested numbers up to 15 significant digits, excluding unsafe large integers. Record dates with an explicit zone. Comparison is literal: the tool does not reconcile different descriptions or date formats.

Fictional example: identical trade, different commission

Assume a linear contract, a USD account and one closed trade with two fills. Its price result is 10 USD. Prices, quantity and period match; financing and other charges are zero. Run A declares commission of 1 USD per fill in costs; B declares 2 USD. These are assumptions for our example, not a broker’s tariff.

A produces 10 − 2 × 1 = 8 USD. B produces 10 − 2 × 2 = 6 USD. Costs explain the 2 USD difference. It does not prove worse signals, faulty data or slippage. The comparator should flag the changed cost field; interpreting that change still requires checking the report and the remaining assumptions.

One trade, two cost assumptions

One trade, two cost assumptionsFictional price P/L 10 USD. Two fills cost 2 USD in A and 4 USD in B. Net results 8 and 6 USD.One trade, two cost assumptionsRun APrice P/L: +10 USD1 USD per fill2 × 1 = 2 USD costsNet: +8 USDOne declared changeField: costsPrices and quantity matchNet difference: 2 USDModel, not a tariffRun BPrice P/L: +10 USD2 USD per fill2 × 2 = 4 USD costsNet: +6 USDAssumptions: 1 trade, 2 fills, other charges = 0.
Conclusion: commission alone explains this model’s difference. The comparator does not verify that declared conditions match reality.

What if the records still appear identical?

Find the first different execution: signal time, symbol, price side, quantity and entry or exit reason. Final balance can conceal a divergence at the first indicator reading. Record no-trade decisions too. Change one condition in a controlled rerun and keep the previous report. Changing several settings together makes it harder to attribute an effect to a particular cause.

Check file dependencies and program initialization. Tester documentation distinguishes the agent environment from the terminal, including global variables and file operations. If your code uses random values, preserve how the generator is initialized. Do not attribute every difference to a cache, or discard the archive as the first diagnostic action. Preserve what you need to reproduce the original observation.

Matching declarations are the beginning of a more detailed investigation. The manifest may omit a dependency or describe the data incorrectly. Do not automatically select the better result or label the worse one a platform fault. Our version and evidence register explains further validation, while the MT4 and MT5 guide covers settings.

What to do after comparing the two runs?

  1. Keep reports A and B separately and complete the thirteen fields. Connect declared identifiers to the correct archives of code, data and settings. Where documentation is missing, record the unknown instead of inventing a version to make the form appear complete.
  2. Select one difference and examine its consequences in a short controlled example. For commission, reconcile the number of fills and charges; for a start-date change, identify the first available signal. Preserve runs that fail to confirm the initial explanation as well.
  3. If declarations match, locate the first diverging journal event. Establish which information is needed to reproduce the decision and expand your own archive. Return to strategy assessment after explaining the cause. This comparator does not predict future returns or certify historical results.