Eval evidence in Quality Center

Fabric Experiments keeps one evidence system. When an eval run concludes, it writes a companion Quality Center test-run row (source eval-run, suite evals) — the same table BDD scenarios and live workload checks report into, and the same rows the production promotion gate consults.

Native managed MLflow runs can participate without moving their underlying evidence. fx test import-mlflow reads the run summary through the Databricks workspace API, applies explicit metric thresholds, publishes source databricks-mlflow, and keeps a deep link to the authoritative run. See Databricks-native AI quality.

Pass/fail policy

A run's evidence status is derived from its binary evaluators: the run fails if any binary evaluator's pass rate lands below the run's passThreshold (default 0.9, settable per run at creation). Non-binary evaluators inform the run page but do not gate.

What this means operationally

• A failed eval run appears in Quality Center history alongside every other check, linking back to the run detail with per-item explanations.
• Promotion gates that consult Quality Center see eval failures exactly like test failures — an AI-quality regression can block a release without any additional wiring.
• Evidence rows carry the eval run id (external_id: eval-run:<runId>), so CLI and audit tooling can trace a gate decision to the judged items that caused it.

Guardrails on live experiments

Beyond offline runs, the eval_metric_decline guardrail joins judge pass-rates per experiment variant: a statistically significant drop in a treatment's eval scores versus control feeds the same alert/pause pathway as sample-ratio-mismatch — AI quality participates in experiment safety, not just reporting.