Databricks target packs

Target packs bundle the code and evidence needed to validate a Databricks workload consistently. Each pack provides typed TypeScript interfaces, offline tests, live checks, configuration diagnostics, documentation, and Quality Center metadata.

Use a target pack when you want a supported starting point for a workload instead of assembling REST calls, polling, cleanup, reports, and evidence publication yourself.

Available packs

live-gated means Fabric has run the pack's required check against its named Azure Databricks certification environment. It does not imply certification for every cloud, runtime, network topology, or optional check.

shipped means the typed adapter, live checks, offline tests, CLI integration, documentation, and Quality evidence schema are published. It does not mean Fabric has certified a customer-specific licensed resource. A shipped pack becomes live-gated only after its required checks pass in a named environment.

The lakeflow-jobs certification passed on Azure Databricks serverless Jobs in West US using a restricted service principal authenticated to the workspace through Databricks OAuth M2M over the public network path. The disposable matrix covered task values, an explicit retry, a condition branch, for_each, an injected failure, targeted repair, cancellation, task outcomes, and cleanup. That scope does not certify other clouds, private networking, schedules, notifications, or every supported task type.

The aibi-genie, mlflow-lifecycle, feature-engineering-serving, model-serving-gateway, and vector-rag-agents required checks passed in the Azure West US certification workspace using a dedicated service principal and Databricks OAuth M2M over the public network path. The exercised behavior was a published dashboard revision, a Genie conversation start, MLflow experiment and Unity Catalog model-version access, PostgreSQL-backed Synced Table health with a SQL freshness assertion, custom model inference with AI Gateway inference-table configuration, Delta Sync vector retrieval, and a custom PyFunc agent invocation. This evidence does not certify private networking, another cloud, or a customer's model and data contracts.

The other advanced packs were live-gated in the Azure East US 2 workspace with disposable resources. Streaming exercised a serverless Lakeflow pipeline, AUTO CDC, and query-based ingestion from a PostgreSQL-backed foreign catalog. Federation exercised the managed PostgreSQL connection, a Delta Share, and an active two-metastore Clean Room. Security and DR exercised an enabled TEST-NET block list, bounded compute policy, billing system-table assertion, and a temporary serverless warehouse in a separate West US 3 workspace. Cleanup removed the pipelines, share, Clean Room, policy, access list, workspace files, schema, and warehouse after evidence collection.

Fabric repeats the managed-resource checks and disposable infrastructure checks every week. The workflow uses one dedicated OAuth M2M certification identity in both workspaces, publishes each pack's evidence to Quality Center, retains the CI artifact, and runs an idempotent cleanup sweep even after failure. A weekly pass proves the named fixtures still work; it does not turn a customer-specific topology into a certified target.

List and diagnose packs

Install the CLI or run it directly:

npm install -g @fabricorg/experiments
fx targets list
fx targets list --json

doctor checks configuration without creating or changing a Databricks resource:

fx targets doctor sql-delta
fx targets doctor lakeflow-jobs --json

The output names missing environment variables and checks. Secret values are never printed.

Foundation pack configuration

The five foundation packs compose the lower-level checks documented in the live-check reference. Start with doctor; it reports the exact variables required by the checks you select.

SQL and Delta foundation

Use sql-delta for Statement Execution, table contracts, time travel, performance budgets, failure recovery, backup/restore, and rollback. Configure DATABRICKS_HOST, Databricks authentication, and either DATABRICKS_WAREHOUSE_ID or DATABRICKS_HTTP_PATH. Optional checks require their own disposable table and budget variables.

Lakeflow ingestion foundation

Use lakeflow-ingestion for pipeline refreshes, Volume fixture I/O, Auto Loader ingestion, and rescued-data assertions. Configure the workspace and authentication, then supply the pipeline, Volume, and destination-table variables for the checks you require.

Jobs and code foundation

Use jobs-code to validate an existing Job plus disposable notebook, dbt, serverless, and classic-compute probes. The default gate requires an existing DBX_TEST_JOB_ID; the other checks remain opt-in so teams can match their actual compute and code surfaces.

Unity Catalog and storage foundation

Use unity-storage to prove both allowed and denied Unity Catalog access, Volume I/O, secret-scope metadata, and rotation behavior. Run it with a dedicated least-privilege identity and disposable resources; secret values are never requested or written to evidence.

Apps and operational data foundation

Use apps-operational for Databricks App state and resource bindings plus Lakebase OAuth credential exchange, query round trips, and pool refresh. Supply the App and Lakebase variables only for the checks you want to make required.

Advanced workload packs

All advanced packs fail closed unless the live identity matches DBX_TEST_RESTRICTED_PRINCIPAL_ID through OAuth M2M. A developer profile may be used for diagnosis, but it cannot produce passing release evidence.

The advanced pack commands validate configured resources. They do not create, modify, publish, or delete dashboards, models, shares, Clean Rooms, network controls, or failover workspaces. This makes doctor and the control-plane probes safe to run with a least-privilege service principal. Data-plane checks run only when their assertion or request variable is present. The separate repository certification runner provisions and removes disposable fixtures for the infrastructure-heavy packs.

Start by listing the exact requirements:

fx targets doctor streaming-cdc-connect
fx targets doctor vector-rag-agents --json

Advanced streaming, CDC, and Lakeflow Connect

Configure DBX_TEST_STREAMING_PIPELINE_ID, DBX_TEST_STREAMING_TABLE, and DBX_TEST_CONNECT_PIPELINE_ID. Use boolean SQL assertions to prove behavior, not just resource existence:

export DBX_TEST_CDC_ASSERTION_SQL='SELECT count(*) = count(DISTINCT order_id) FROM qa.orders_cdc'
export DBX_TEST_STREAMING_ASSERTION_SQL='SELECT max(event_time) > current_timestamp() - INTERVAL 15 MINUTES FROM qa.events'
export DBX_TEST_CONNECT_ASSERTION_SQL='SELECT count(*) > 0 FROM qa.replica_orders'
fx targets run streaming-cdc-connect --live

The pipeline and streaming table must be healthy, every configured SQL assertion must return a truthy first column, and the Connect pipeline must contain a non-empty managed ingestion definition. A generic Lakeflow pipeline cannot satisfy the Connect check.

The repeatable Fabric certification currently uses query-based ingestion from a PostgreSQL-backed Unity Catalog foreign catalog. Direct PostgreSQL CDC through Lakeflow Connect is a separate Databricks-gated capability and is not claimed until that connector is enabled and the same disposable assertion passes.

Fabric's repository also includes a repeatable disposable certification runner for the three advanced infrastructure packs:

pnpm certify:databricks:advanced

Configure its DBX_CERT_* variables for the primary profile/catalog/warehouse, an existing PostgreSQL-backed foreign catalog, and a separate-region workspace plus service principal. The runner creates a unique schema, streaming and query-based ingestion pipelines, TEST-NET block list, bounded compute policy, Delta Share, two-metastore Clean Room, and secondary serverless warehouse. It runs all three target packs with a dedicated OAuth M2M service principal and removes the resources in a trap. If the process is interrupted, rerun cleanup with the emitted ID:

scripts/certify-advanced-databricks.sh cleanup fx_adv_YYYYMMDDHHMMSS

Cleanup discovers named resources and uses the local .fx state only for opaque IDs. Use dedicated certification workspaces: an account administrator must enable INTERNAL_AND_EXTERNAL sharing on both participating metastores as a one-time prerequisite. The recurring service principal cannot mutate or read that account-admin setting; Clean Room creation fails closed if it is absent.

AI/BI dashboards and Genie

Set DBX_TEST_DASHBOARD_ID, DBX_TEST_GENIE_SPACE_ID, and a safe DBX_TEST_GENIE_QUESTION. The dashboard check requires both an accessible draft and a published revision. The question starts a real authenticated conversation and requires Genie to return a conversation or message ID.

export DBX_TEST_GENIE_QUESTION='Which product had the largest week-over-week change?'
fx targets run aibi-genie --live

MLflow and model lifecycle

Set DBX_TEST_MLFLOW_EXPERIMENT_ID, DBX_TEST_REGISTERED_MODEL using its three-part Unity Catalog name, and DBX_TEST_MODEL_VERSION. The check resolves the experiment, registered model, and exact version through their supported APIs and rejects failed lifecycle state.

Feature engineering and serving

Set DBX_TEST_FEATURE_TABLE plus either DBX_TEST_ONLINE_TABLE for the Online Tables API or DBX_TEST_FEATURE_SERVING_PIPELINE_ID for a PostgreSQL-backed Synced Table. The online table must report an online/active/ready state; the Synced Table pipeline must not be failed. DBX_TEST_FEATURE_ASSERTION_SQL to enforce freshness, null-rate, point-in-time correctness, or another business contract against the offline feature table.

Model Serving and AI Gateway

Set DBX_TEST_SERVING_ENDPOINT, put a safe inference request in DBX_TEST_SERVING_REQUEST_JSON, and set DBX_TEST_AI_GATEWAY_REQUIRED=1. The pack fails unless the endpoint is ready, inference returns a non-empty response, and the endpoint exposes AI Gateway configuration.

Request JSON may contain customer data, so store it as a CI secret rather than as a repository variable. Evidence records only readiness and whether an invocation ran; it does not include the request or response body.

Vector Search, RAG, and agents

Set DBX_TEST_VECTOR_ENDPOINT and the three-part DBX_TEST_VECTOR_INDEX, a safe DBX_TEST_VECTOR_QUERY_JSON, DBX_TEST_AGENT_ENDPOINT, and DBX_TEST_AGENT_REQUEST_JSON. Certification requires both a real retrieval result and an end-to-end agent invocation.

export DBX_TEST_VECTOR_QUERY_JSON='{"query_text":"retention policy","num_results":3}'
fx targets run vector-rag-agents --live

Federation, Delta Sharing, and Clean Rooms

Set DBX_TEST_CONNECTION, DBX_TEST_SHARE, DBX_TEST_CLEAN_ROOM, and DBX_TEST_FEDERATION_ASSERTION_SQL to prove the restricted principal can query the intended foreign catalog. The check reads metadata only for the share and Clean Room; it never mutates recipients, assets, or collaborators.

Networking, security posture, cost, and regional DR

Set an enabled DBX_TEST_IP_ACCESS_LIST_ID, a DBX_TEST_CLUSTER_POLICY_ID, and a boolean DBX_TEST_COST_ASSERTION_SQL. Optionally enforce the workspace hostname with DBX_TEST_EXPECT_HOST_SUFFIX. For secondary-region readiness, configure DBX_TEST_DR_HOST, DBX_TEST_DR_WAREHOUSE_ID, and separate DBX_TEST_DR_CLIENT_ID / DBX_TEST_DR_CLIENT_SECRET credentials. The DR check authenticates to the secondary workspace, requires its warehouse to be running, and executes the boolean workload assertion in DBX_TEST_DR_ASSERTION_SQL there.

export DBX_TEST_COST_ASSERTION_SQL='SELECT sum(usage_quantity) < 1000 FROM system.billing.usage WHERE usage_date >= current_date() - 1'
fx targets run security-cost-dr --live

An API reachability result is a readiness check, not a recovery-time or recovery-point claim. Measure workload failover separately and publish that evidence alongside the pack result in Quality Center.

MLflow 3 agent quality and monitoring

mlflow3-agent-quality runs a customer-owned Databricks Job that uses the native MLflow 3 Python APIs, then independently requires four boolean SQL assertions. Configure DBX_TEST_MLFLOW3_JOB_ID, the DBX_TEST_MLFLOW3_{TRACE,EVAL,SCORER,MONITOR}_ASSERTION_SQL variables, and DBX_TEST_AI_SEARCH_EVAL_ASSERTION_SQL. The Job must write durable proof of a trace, offline evaluation result, complete production-scorer lifecycle, production monitor output, and AI Search retrieval-quality thresholds. A successful Job without every assertion fails certification.

This pack complements the Experiments evaluation runner. Experiments owns the release threshold and Quality evidence; MLflow remains authoritative for its native traces, scorers, review data, and monitoring tables.

Fabric's repeatable fixture composes the governed 50-record RAG evaluation with a second serverless notebook task that registers and starts a scorer, emits fresh traces while sampling is 100%, and waits for real asynchronous feedback before exercising update, stop, restart, and delete. Deferring lifecycle churn until after feedback avoids racing the monitor's activation window. Each observed phase is appended to a Delta evidence table. Provision or update that Job with:

pnpm provision:databricks:agent-quality

The command defaults to the fabric-harness Databricks CLI profile and the shared Harness RAG notebook. Override DBX_CERT_PROFILE, DBX_MLFLOW3_RAG_NOTEBOOK, DBX_MLFLOW3_MONITOR_NOTEBOOK, DBX_MLFLOW3_JOB_NAME, or DATABRICKS_MLFLOW3_EVIDENCE_TABLE for a customer workspace. Set DBX_MLFLOW3_RUN_AS_SERVICE_PRINCIPAL so the saved Job and its native MLflow evidence use the same restricted identity as certification. Grant that identity READ VOLUME, WRITE VOLUME only on the configured RAG evidence Volume; evaluation can finish successfully and still fail certification if the durable JSON evidence cannot be written. The judge uses Databricks' hosted default; set DBX_MLFLOW3_SCORER_MODEL to a permitted databricks:/<endpoint> when the customer requires a pinned model. If omitted, the provisioner derives that value from DBX_TEST_SERVING_ENDPOINT when it is set. The notebook also accepts DATABRICKS_MLFLOW3_SCORER_MODEL for direct runs. It first executes Safety synchronously to prove model and trace-output compatibility, then keeps emitting traces beyond Databricks' documented 15–20 minute activation window and waits up to 40 minutes. A missing asynchronous feedback assessment fails the Job and cannot be replaced with “scorer configured” or the synchronous preflight.

Managed MCP and MCP Services

managed-mcp-agents uses a native fixture Job because Databricks MCP endpoints use Streamable HTTP and preview client details can change independently of the testkit. Configure DBX_TEST_MCP_JOB_ID plus the managed-server, MCP-Service, and denial assertion SQL variables. The fixture must initialize a session, list and call a tool on a Databricks managed MCP server, list and call a tool on a Unity Catalog MCP Service, and demonstrate that a tool excluded by the service's Unity Catalog selector is rejected with MCP error -32003.

Provision or update the serverless fixture Job with:

pnpm provision:databricks:managed-mcp

The defaults certify the shared AI Search index and a governed MCP Service. Customer workspaces override DATABRICKS_MCP_MANAGED_SERVER, DATABRICKS_MCP_SERVICE, DATABRICKS_MCP_MANAGED_TOOL, DATABRICKS_MCP_SERVICE_ALLOWED_TOOL, DATABRICKS_MCP_SERVICE_DENIED_TOOL, and DATABRICKS_MCP_EVIDENCE_TABLE. Set DBX_MCP_RUN_AS_SERVICE_PRINCIPAL to make the saved Job execute as the same restricted principal used by release certification.

Before provisioning, register the external Streamable HTTP server as a UC MCP Service, store its credential in an HTTP connection, grant the Job identity EXECUTE, and configure include_tool_selectors so the allowed tool is exposed and the denial probe is not. Follow Databricks' managed MCP server, MCP Service registration, and MCP governance guides. The fixture uses the official databricks-mcp client and never writes the external credential or returned tool content into the evidence table.

The pack certifies the customer identity and selected fixtures. It does not grant new tools, copy OAuth tokens into evidence, or imply access to every managed MCP server.

Data quality and Databricks Apps observability

data-quality-observability first verifies that DBX_TEST_TELEMETRY_APP_NAME has a Unity Catalog telemetry destination with logs, traces, and metrics tables. It then executes boolean assertions supplied through DBX_TEST_DQM_ASSERTION_SQL and DBX_TEST_APP_{LOGS,SPANS,METRICS}_ASSERTION_SQL. Use the DQM assertion against system.data_quality_monitoring.table_results to require current freshness and completeness evidence for the intended schema. Scope the service principal carefully because the DQM system table can contain metastore-wide sample data. For a release gate, require a latest row where both freshness.status and completeness.status are Healthy, reject latest Unhealthy or Error rows, and apply an explicit recency window. A newly enrolled table whose consolidated status is still Training proves enrollment but does not satisfy that release gate; Databricks must finish building its historical baseline first. Logs are emitted by the Databricks Apps runtime. Spans and metrics require custom OpenTelemetry instrumentation; the supplied Harness worker emits health and lifecycle spans plus liveness/readiness gauges through the runtime-injected OTEL_EXPORTER_OTLP_ENDPOINT. All three assertions must target the dedicated custom-storage telemetry schema, and the App must be redeployed after its telemetry destination changes.

Unity Catalog Agent Services enrollment

agent-services-enrollment verifies a customer-owned Harness agent registered as an external Agent Service. Configure its three-part full name, expected UC HTTP connection, and principal that must have EXECUTE. The check rejects a non-external service, a connection mismatch, a missing absolute base path, or a missing grant.

Agent Services is Beta and currently provides registration, discovery, and governance rather than runtime invocation. The pack deliberately records runtimeInvocationAvailable: false; execution is tested through the customer-owned Harness worker and its run attestations instead.

Agent evaluation delivery pipeline

agent-evaluation-pipeline certifies the application path, not only evaluator library units. DBX_TEST_EVAL_SERVING_ENDPOINT must satisfy the deterministic judge label and token-usage contract. DBX_TEST_AGENT_EVAL_E2E_JOB_ID then submits a real evaluation through the exact candidate API and waits for outbox dispatch, Temporal execution, Databricks Model Serving inference, SQL score persistence, and terminal Quality completion. The boolean query in DBX_TEST_AGENT_EVAL_ASSERTION_SQL must prove the final score/evidence rows.

A directly successful Model Serving request cannot substitute for this check; both checks are required.

Provision or update the serverless fixture with:

pnpm provision:databricks:agent-evaluation

The Job reads its hosted Experiments API key from a Databricks secret, exchanges the notebook's internal token for an OAuth token scoped to the exact Experiments App audience, resolves the key's tenant through /v1/tenants/me, creates a dedicated immutable dataset fixture when necessary, and submits relevance plus qa-correctness judges. It requires a successful API run, at least four API scores, the same scores in the configured Delta table, and a passing source=eval-run, suite=evals Quality row before writing its own pipeline_complete evidence. Judge explanations and credentials are never copied into the certification table.

Override FX_AGENT_EVAL_API_BASE_URL, FX_AGENT_EVAL_APP_NAME, FX_AGENT_EVAL_SECRET_SCOPE, FX_AGENT_EVAL_API_KEY_SECRET, FX_AGENT_EVAL_DATASET_ID, FX_AGENT_EVAL_SCORES_TABLE, or FX_AGENT_EVAL_EVIDENCE_TABLE for the customer deployment. Set DBX_AGENT_EVAL_RUN_AS_SERVICE_PRINCIPAL to the release identity and grant it CAN_USE on the Experiments App, READ on the API-key secret, and SELECT/MODIFY on the certification schema. The worker must run with FX_EVAL_DISPATCH=worker, a reachable Temporal namespace, the same worker token as the control plane, a Databricks Model Serving endpoint, and its score-sink catalog/schema.

Next-generation workload packs

These packs use a native Databricks Job to exercise the workload and then query durable evidence through a SQL warehouse. This boundary is intentional: preview Python clients and workspace APIs can change without weakening the stable target-pack contract. A successful Job is insufficient; every declared assertion must return a truthy first column.

All packs require DATABRICKS_HOST, OAuth M2M credentials, DBX_TEST_RESTRICTED_PRINCIPAL_ID, and a SQL warehouse.

Semantic analytics and SQL operations

semantic-analytics requires DBX_TEST_SEMANTIC_ANALYTICS_JOB_ID and boolean assertions for a metric-view query, materialization freshness, SQL alert, and query-performance budget. It certifies the semantic definition and its operational consumers rather than accepting object existence alone.

AI Functions and batch inference

ai-functions-batch-inference requires DBX_TEST_AI_FUNCTIONS_JOB_ID plus output, quality, and lineage assertions. The fixture may use a scheduled workflow, Lakeflow pipeline, or Structured Streaming, but retained output must identify the exact candidate and governed source.

Knowledge Assistant, multi-agent, and Responses

agent-orchestration-responses requires a native orchestration Job plus durable assertions for Knowledge Assistant, multi-agent routing, Responses API completion, and groundedness. The pack remains shipped rather than live-gated until all preview features are enabled in the named workspace.

AI Runtime training and fine-tuning

ai-runtime-training requires an AI Runtime Job and assertions proving the training run, evaluation result, and exact Unity Catalog model version. It does not certify deprecated Foundation Model Fine-tuning APIs.

Lakebase Autoscaling Online Feature Store

lakebase-autoscaling-features requires an Online Feature Store publication Job and assertions for online publication, Feature Serving lookup, and freshness. This is separate from the existing PostgreSQL-backed Synced Table evidence.

Declarative Automation Bundles

declarative-bundles requires a bundle-managed Job and durable assertions for deployment provenance, exact candidate identity, and rollback. Bundle validation and deployment occur in CI; the target pack proves the deployed artifact behaved as declared.

Lakehouse optimization and Iceberg

lakehouse-optimization uses SQL assertions for Predictive Optimization, liquid clustering, and Iceberg interoperability. It does not mutate table layout; fixture provisioning owns those changes.

Marketplace and OpenSharing

marketplace-open-sharing requires a provider/consumer fixture Job and assertions for listing visibility, recipient access, and usable shared data or AI assets. Public marketplace publication is not required; certification can use an isolated private exchange.

Run a pack

Live execution is fail-closed. You must pass --live or set DBX_TEST_LIVE=1:

fx targets run sql-delta --live \
  --required sql,delta-contract \
  --evidence reports/sql-delta.json \
  --junit reports/sql-delta.xml

Authentication is resolved in this order:

1. DATABRICKS_BEARER
2. DATABRICKS_CLIENT_ID and DATABRICKS_CLIENT_SECRET
3. Databricks OIDC environment or token file
4. DATABRICKS_TOKEN

Use a dedicated workspace identity and disposable catalog/schema/resources. Required grants depend on the selected pack; doctor reports the resource configuration it can validate before execution.

Lakeflow Jobs orchestration

The Jobs adapter accepts a typed JobsSubmitRequest and validates task keys, dependencies, unknown references, self-dependencies, and cycles before submission.

import {
  DatabricksJobsAdapter,
  type JobsSubmitRequest,
} from '@fabricorg/databricks-testkit'

const request: JobsSubmitRequest = {
  run_name: 'orders-contract',
  tasks: [
    {
      task_key: 'seed',
      notebook_task: { notebook_path: '/Workspace/Shared/orders-seed' },
      max_retries: 2,
      retry_on_timeout: true,
    },
    {
      task_key: 'validate',
      depends_on: [{ task_key: 'seed' }],
      notebook_task: { notebook_path: '/Workspace/Shared/orders-validate' },
    },
  ],
}

const adapter = new DatabricksJobsAdapter(client)
const runId = await adapter.submit(request)
const result = await adapter.wait(runId)

Supported typed task forms include notebooks, Python wheels, JARs, Spark Python, Spark submit, pipelines, SQL, dbt, nested Jobs, conditions, and for_each tasks. The adapter also exposes get, cancel, and repair.

For a live pack run, provide the scenario as JSON:

export DBX_TEST_JOBS_ORCHESTRATION_JSON='{
  "request": {
    "run_name": "orders-contract",
    "tasks": [
      {
        "task_key": "seed",
        "notebook_task": { "notebook_path": "/Workspace/Shared/orders-seed" }
      },
      {
        "task_key": "validate",
        "depends_on": [{ "task_key": "seed" }],
        "notebook_task": { "notebook_path": "/Workspace/Shared/orders-validate" }
      }
    ]
  },
  "expectedResult": "SUCCESS",
  "expectedTasks": { "seed": "SUCCESS", "validate": "SUCCESS" }
}'

fx targets run lakeflow-jobs --live

Fabric's extended disposable certification check is opt-in because it creates multiple runs and intentionally fails, repairs, and cancels work:

export DBX_TEST_JOBS_CERTIFY=1
fx targets run lakeflow-jobs --live --required jobs-certification

The identity needs permission to import and delete notebooks beneath DBX_TEST_JOBS_FIXTURE_ROOT (default: /Workspace/Shared/fabric-experiments-target-pack) and permission to submit, repair, and cancel Jobs runs.

--required adds checks to the pack's immutable required baseline. It cannot remove identity, denial, quality, or cleanup controls declared by the pack.

Use target packs in TypeScript

import {
  builtinTargetPacks,
  createTargetPackRegistry,
  doctorTargetPack,
  runTargetPack,
} from '@fabricorg/databricks-testkit'

const registry = createTargetPackRegistry(builtinTargetPacks)
const pack = registry.get('sql-delta')
if (!pack) throw new Error('sql-delta pack is unavailable')

const diagnosis = doctorTargetPack(pack, process.env)
if (!diagnosis.ready) {
  throw new Error([...diagnosis.missingRequirements, ...diagnosis.missingRequiredChecks].join(', '))
}

const evidence = await runTargetPack(pack, {
  env: process.env,
  evidencePath: 'reports/sql-delta.json',
  junitPath: 'reports/sql-delta.xml',
})

The API is additive to the lower-level live checks. Existing check exports remain available when you need a custom suite.

Publish evidence to Quality Center

Target-pack evidence contains the pack ID, version, maturity, capabilities, certification scope, cloud, region, workspace, runtime, and compute metadata. Credentials and secret values are excluded or redacted.

fx login --api-key fx_key_...
fx targets publish reports/sql-delta.json

Quality Center stores the run inside the authenticated organization. Open Quality in Studio to filter history by target-pack ID and inspect cases, durations, environment metadata, and failure evidence.

Current boundaries

• Azure Databricks is the certified cloud target. AWS and Google Cloud are not currently certified targets.
• A pack's certification is limited to the compute, runtime, identity, and topology named in its evidence.
• Live packs can create, execute, repair, or delete disposable Databricks resources. Use an isolated test environment and least-privilege identity.
• Fabric stores governed summaries and attachments. Specialized tools remain authoritative for detailed Playwright traces, load-test samples, or SARIF.
• Python, R, SQL, and Scala workloads can be tested, but Fabric's extension and step-definition API is TypeScript.

See Certification evidence for verified target boundaries and Quality Center for publication, authentication, tenancy, and production-gate behavior.