XTester Lab: comparing branches of an experiment

You add a market-phase filter to a strategy, and the result improves. What changed? Perhaps the filter removed bad entries. Perhaps it left too few trades to judge. Or the selected period simply suited the change.

Keeping the original strategy beside its descendants makes that question easier to investigate. This is the workflow we are developing for XTester Studio’s lab: choose a base version, state a hypothesis, run a separate experiment and compare it with its parent. We are planning the Studio release for September 30, 2026.

Give each branch a question

Consider a breakout strategy. One hypothesis allows new entries only during a rising market phase. Another keeps the entry rules and changes the exit. This is an example research setup, not a reported test result.

Changing both at once makes it harder to explain the outcome. Separate branches preserve the question behind each run: an entry change here, an exit change there, with the original still available as a reference. A promising version can become the starting point for further experiments without losing its ancestry.

Keep the instrument, historical period and cost assumptions fixed when comparing those changes. Different data or fees change the question. Testing another market is useful too, but it should be identified as a separate experiment.

A phase filter can improve selected stretches while the strategy still loses over the full period. The conclusion needs to cover both: where the filter helped and what happened across the complete history. Trade count matters as well. A handful of entries gives you less evidence than a much longer series.

What the workspace should show

The proposed lab layout puts branches and versions on the left, the research conversation in the centre, and test conditions plus a candidate version on the right. A version appears alongside its hypothesis and parent, so its meaning does not depend on remembering a filename.

The layout keeps the market, period, phase focus and costs visible. Opening a version, comparing it and applying it to the project are separate actions. That separation gives the user a chance to inspect an experimental result before replacing the code they will continue working with.

The figures in the Russian-language design reference below illustrate the layout, not a published backtest or evidence of profitability.

Working through MCP

MCP lets an external agent call XTester functions. The published catalogue for version 0.0.91 already describes individual lab operations. Together, they outline a useful workflow:

1. lab_create_research creates a research task from a title and specification. It does not generate a strategy or run a backtest yet.
2. lab_start_initial_strategy starts the first version. Long-running work returns a jobId, which is checked with job_status.
3. lab_improve takes a research task, a starting version and an instruction for one experiment.
4. lab_compare_versions compares two versions, including strategy changes, backtest metric differences and robustness results.
5. lab_get_graph returns research relationships and version ancestry. lab_get_version provides the selected version’s code and associated test details.
6. lab_apply_to_project writes the selected version’s code into the current project, overwriting strategy files. It is a separate modifying action that should be explicitly requested.

These operations are documented in the current XTester catalogue; the Studio window shown above is still being designed. Use the catalogue when working through an agent. The mockup shows how we intend to organise branch comparisons in the interface.

What to keep from a run

A useful research conclusion names the starting version, the change, the comparison conditions and what remains unproven. The best result within a branch does not establish that it will hold on another period or work with real money.

Preserve the baseline and give the next experiment its own hypothesis. When an agent does the work, ask for the original version, the code change and both sets of results before applying anything to the project. That is enough to make a concrete decision about whether this branch deserves another experiment.

Public references: MCP tool catalogue, MCP scenarios and their verification status.