Skip to main content

Version Available Metrics

GET 
/datasets/:dataset_id/versions/:version_id/available-metrics

Which metrics can score this dataset version, and why not.

Each metric is checked with the same function POST /runs gates on, over the same op rows and column set, so a metric reported available is one the run gate accepts and an unavailable one carries the exact 422 detail the user would have hit at submit.

has_connection (default true) says whether inference will fill the produced columns (sut_response, retrieved_context) before scoring, which the only pipeline reaching this picker always does. Passing false judges the version's at-rest columns alone, and so reports every answered metric unavailable.

metrics (repeatable) restricts the report to those names; omit it for every metric visible in the dataset's workspace, ordered by name. A requested name that resolves to no metric is reported OpNotFound rather than dropped, so a stale client selection gets a real answer.

Columns come from what the version recorded at map time, not a live DESCRIBE of the dataset's current table — the same input the run gate uses, and the two can legitimately differ for an older golden version.

Trace datasets are rejected with 422: their metrics score materialized partition occurrences rather than the dataset's own schema, so the answer here would be a technically-correct "nothing is available" that reads as broken.

Request​

Responses​

Successful Response