Databricks-native AI quality

Fabric Experiments is an adoption accelerator for Databricks, not a replacement for Databricks AI tooling. Managed MLflow remains authoritative for native evaluation runs, scorers, traces, evaluation datasets, feedback, and model lineage. Unity Catalog remains the governance boundary. Model Serving and AI Gateway remain the inference and serving-governance layer.

Fabric adds the parts that span those native surfaces: TypeScript developer workflows, Databricks workload tests, A/B experiment guardrails, durable automation, and one Quality Center release decision.

Choose the native path first

Use managed MLflow when a capability is already available there:

• create and version evaluation datasets;
• run built-in, custom, or multi-turn scorers;
• retain traces and human feedback;
• compare model or agent versions;
• continuously score production traces;
• preserve model, prompt, dataset, and run lineage.

Use Fabric around that run when you need to combine its outcome with BDD, Lakeflow, SQL, Delta, Jobs, application, security, recovery, or A/B experiment evidence before a release is promoted.

Link a managed MLflow run

First create and evaluate the run using Databricks and MLflow. Then define the small release policy Fabric should enforce over metrics recorded on that run:

export DATABRICKS_HOST="https://adb-<workspace-id>.<region>.azuredatabricks.net"
export DATABRICKS_TOKEN="..." # OAuth M2M is recommended for CI

fx login --profile production
fx test import-mlflow <run-id> \
  --workspace-host "$DATABRICKS_HOST" \
  --gates "accuracy>=0.90,toxicity<=0.02" \
  --suite "Support agent release quality"

For OAuth M2M, set DATABRICKS_CLIENT_ID and DATABRICKS_CLIENT_SECRET instead of DATABRICKS_TOKEN. The service principal needs permission to read the MLflow experiment and run. The Fabric publisher key only needs permission to publish Quality Center evidence for its organization; the two credentials have separate trust boundaries.

The command exits with:

• 0 when the native run is terminal and every configured metric gate passes;
• 2 when a gate fails or a required metric is missing;
• 1 for configuration or usage errors.

What Fabric stores

The published Quality Center row contains:

• the Databricks workspace and managed MLflow run and experiment identifiers;
• the native run status;
• each metric name, operator, threshold, and observed value;
• an immutable external id, databricks-mlflow:<run-id>, for idempotent CI retries;
• a deep link back to the native MLflow run.

Fabric does not copy MLflow artifacts, traces, datasets, scorer implementations, or model lineage. evidenceOwnership: databricks is recorded on the Quality row so Studio and downstream audit exports preserve that boundary.

Missing metrics fail closed. Re-running the command updates the same Quality row because publication is idempotent on the native run id.

TypeScript evaluators remain an integration option

The provider-neutral evaluator contract is useful when a TypeScript application needs deterministic code checks, local CI, or a scorer that must run inside its existing Node workflow. In production, its LLM judge calls use Databricks Model Serving and its score sink uses Databricks SQL and Delta.

That path complements managed MLflow; it does not redefine MLflow APIs or AI Gateway controls. Prefer native managed MLflow evaluation when it satisfies the use case, and use the TypeScript path for application-side orchestration or cross-workload checks that are not represented by a native scorer.

Release architecture

The result is more Databricks usage—not a parallel model platform: teams use native Model Serving, MLflow, Unity Catalog, AI Gateway, SQL, Delta, and Lakeflow while Fabric shortens the path from development evidence to a safe production decision.