Introduction

A metric declares which parts of a test case it reads. That declaration is not bookkeeping — it decides which cases the metric can score at all, and it is the most common reason a metric silently does nothing.

The standard parameters

Group	Parameters	Supplied by
Input	`Input`, `Context`, `Expected Output`, `Expected Tools`	You, in the dataset
Output	`Actual Output`, `Retrieval Context`, `Tools Called`	The run
Conversational	`Turns`, `Agent Role`	Conversational cases
Additional	`Latency`, `Cost`	Measured during the run
Metadata	Custom fields on your cases	You

At least one parameter is required — the editor says so: "Please select at least one parameter." A metric reading nothing has nothing to judge.

Note: A metric can only score a case that carries every parameter it declares. Declare Context and the metric skips cases without it. This is the single most common cause of "my metric produced no results" — the metric was fine, and the cases were missing a field it asked for.

Parameters determine what you can measure

Question	Parameters
Did it give the right answer?	`Actual Output` + `Expected Output`
Did it stay faithful to the facts?	`Actual Output` + `Context`
Did it actually address the question?	`Actual Output` + `Input`
Did retrieval find the right material?	`Retrieval Context` + `Context`
Did it take the right action?	`Tools Called` + `Expected Tools`
Was it efficient?	`Latency`, `Cost`

Declare the minimum

Over-declaring is the failure mode, and it is asymmetric: a parameter you declare and do not need costs you every case that lacks it, while one you need and did not declare fails loudly and gets fixed.

A faithfulness metric needs the output and the ground truth. Adding Expected Output because it seems related silently drops every case where you did not write one — and those are often exactly the open-ended cases faithfulness matters most for.

"Every extra parameter is a filter on which cases you are allowed to score. Declare what you read, not what you have."

Custom fields

Cases can carry fields of your own, and a metric can declare them like any standard one. This is how domain-specific checks get written — a case carrying a policy reference, a customer tier, or a jurisdiction gives a metric something to reason about that no standard field expresses.

The same constraint applies with more force: a metric declaring a custom field scores only cases carrying it. Populate it across the dataset, or accept a partial score.

When a metric returns nothing

Check its declared parameters against your cases — Nine times in ten, a declared field is missing from the cases.
Check the case type — Conversational parameters do not exist on an LLM case, and vice versa.
Check output parameters are populated — They are filled by the run. If the run did not complete, they are empty.

Input Parameters Reference