Read and compare results

A useful result is more than a high score: it includes the exact parameters, image, data assumptions, and logs needed to understand the run. Start by checking one successful trial before comparing the whole experiment.

Check a successful trial

Open the experiment in your project, then inspect a trial in the trials table.

1. Parameters: confirm that the values fall within your search space and reached the intended inputs.
2. Metrics: check that every objective has a numeric value in the expected units.
3. Logs: look for the reported metric and any warnings from the workload.
4. Status and runtime: confirm the run completed instead of timing out or stopping early.

A printed score alone does not prove the workload finished correctly. If the process failed or an objective is missing, use debug trials.

Compare one objective

For a single objective, interpret the best result using its configured direction: lower for Minimize, higher for Maximize. Compare supporting metrics as well.

Trial	Learning rate	Validation loss ↓	Runtime (seconds)
A	0.001	0.241	38.2
B	0.01	0.182	42.1
C	0.1	0.396	37.6

These illustrative results would rank B first for validation loss. Runtime is context here; it does not affect ranking unless you explicitly make it an objective or incorporate it into a score.

Compare multiple objectives

With multiple objectives, review each metric and its direction independently. A trial can be more accurate and slower than another trial. There is no automatic overall winner, weighting, or combined score.

Decide which tradeoffs your workload can accept. Supporting metrics are not automatic filters. If you need a single score, define the calculation in your workload and document its units and weights.

Check that an improvement holds up

• Re-run promising settings when the workload is noisy or stochastic.
• Keep image, dataset, and evaluation conditions consistent when comparing searches.
• Use validation data during search and separate holdout data for your final evaluation.
• Review boundary values: a best trial at the edge may justify a wider range, but it does not prove that going further will help.

For backtests, keep fees, date windows, and execution assumptions consistent. A historical result is evidence about that evaluation, not a guarantee of future performance.

Prepare the next experiment

Open Settings → Export configuration → Export TOML to save the setup. Change a small number of ranges or inputs, then import the file into a new experiment or use the CLI. See experiment TOML.

Keep results you need within your plan’s history window. A TOML export contains configuration, not trial results or logs.

Next: control a running experiment or refine the search space.