`aip_sdk.MetricUnavailableReason`

aip_sdk.MetricUnavailableReason

Why a trace metric cannot score a partition.

The first four are properties of the metric against the occurrence rows it would score; the next four are structural — the partition's granularity, the span kinds its occurrences carry, or (REQUIRED_SHAPE_UNSUPPORTED) the topology of the traces it resolves to, e.g. an orchestrator delegating to subagent(s). PARTITION_HAS_NO_OCCURRENCES is a property of the selector as a whole and answers "why is everything unavailable" for an over-narrowed partition. OP_NOT_DEPLOYED is a property of the environment: the metric exists and fits, but its scoring function is not running here, so a run would fail. Ask whoever operates your platform to deploy it.

AMBIGUOUS_TRACE_GROUND_TRUTH is a property of the ground truth attached to the version. agent.step_accuracy and agent.tool_selection_accuracy fall back to a session's pooled ground truth when a trace carries no annotation of its own — correct for a single-trace session, but a multi-trace one has no single trace whose steps or tool calls should be compared against a trajectory authored for the whole conversation, so both metrics reject that occurrence outright at scoring time rather than silently mis-scoring it (a FAILED row, not a wrong number). Fix by attaching trace-scoped ground truth for the affected traces, or by scoring the metric on a SESSION partition instead.

Reported only when every occurrence a TRACE partition selects would hit that fallback: a partition mixing some traces that carry their own ground truth with others that would fall back to the pooled value still reports available=True — the pooled-fallback traces are still individually rejected if you run it (each becomes a FAILED row, not a wrong score), so available=True never hides a bad number; a mixed partition just doesn't warn you in advance which rows will fail.