Metrics

The Metrics view of a Discovery run lists what every Version is scored on. Each Metric has a direction and an importance tier, and together they decide how Versions are ranked against the Baseline.

Sources

• Execution Metrics are measured on your runner: the built-in runtime, CPU and memory, plus any custom Metrics your benchmark records (for example XXH32_MBps or XXH64_MBps). See Benchmarks for how these are produced.
• LLM Metrics are model-judged: criteria generated from the Objective, such as seed_option_malformed_input_robustness or fix_scope_and_maintainability, that a panel of judge models scores. These are model judgements, not measurements.

Direction

Each Metric is either maximised (Higher is better, for example throughput) or minimised (Lower is better, for example runtime or memory).

Importance

Each Metric has an importance tier: High, Medium, Low or None. Artemis derives the scoring weights from the tiers of the whole set, so there are no numbers to balance by hand. A Metric set to None is still measured and reported, but it does not count toward the Composite score. A Metric nobody has ranked yet shows as Not ranked, and it is treated as Low when setup completes.

Use High for the thing you are trying to improve and lower tiers for Metrics you want to keep an eye on. A low tier does not stop a Version that makes that Metric worse; it only reduces how much that Metric counts, so check the per-Metric results for trade-offs.

You can change direction and importance during a run. Save & recompute re-scores every existing Version, which can change which Version ranks best.