FabricFabricHarness
Databricks

Databricks certification

Public certification status, tested capabilities, evidence scope, and limitations for Fabric Harness on Databricks.

Fabric Harness tests its Databricks integration in protected workspaces before making live-support claims. Certification binds the tested package, source commit, generated Databricks App, workspace profile, and redacted evidence into one retained record. A passing record applies only to that exact scope; it is not a blanket claim for every cloud, region, preview, or workspace configuration.

Certification record

  • Current npm package: @fabric-harness/databricks@7.0.2
  • Exact live-certified package: @fabric-harness/databricks@7.0.2
  • Certification date: August 5, 2026
  • Workspace profile: Azure Databricks, eastus2, OAuth machine-to-machine
  • Consumption checks: 21 of 21 required Tier R checks passed
  • Additional checks: 9 configured Tier O checks passed; 0 checks failed
  • Authoring checks: 10 of 10 required Tier A checks passed with an empty cleanup ledger
  • Source commit: 544cd478d29b26ed7090499c682af0922f4533d1

What the public record shows

Exact-package results and limitations belong in the same view. The image below is a sanitized rendering of the machine-readable public record; the JSON evidence and protected run remain authoritative.

Databricks certification summary showing exact package Tier R, Tier A, optional checks, workspace scope, and unestablished claims
Certification evidence · @fabric-harness/databricks 7.0.2The public record keeps exact-package results and limitations together; it is not a blanket claim for every cloud, region, or preview.

Version 7.0.2 is the byte-identical npm package certified by the Tier R record. The protected publisher independently matched its tarball and generated App digests to the retained evidence before publishing. The focused Tier A workflow then downloaded that exact retained tarball and proved the governed authoring lifecycles against the same source commit and package digest.

The public record promotes 7.0.2 only after exact-commit Tier R, same-package Tier A, guarded publication, public package consumption, and tag verification all passed.

Development builds may be published under the npm dev dist-tag for single-user evaluation. A development-tagged package is explicitly uncertified, does not move latest, does not advance this record, and must not be used to claim shared-user isolation or production readiness. Promoting that exact version to latest still requires the complete protected evidence above.

Tier R runs its 25-request concurrency burst in a fresh 60-second production rate-limit window. This keeps earlier correctness probes from consuming burst capacity while preserving the real 30-request prompt ceiling. Any failed burst request still fails certification, and retained load evidence aggregates non-secret failure categories such as admission_http_429 for diagnosis.

What the protected record proves

The current Tier R record passed:

  • workspace identity and OAuth machine-to-machine authentication;
  • Unity AI Gateway, Model Serving, SQL, and Unity Catalog allow-and-deny controls;
  • governed mutation approval, lineage, Volumes, Lakebase, and System Tables cost reconciliation;
  • RAG, Genie, and managed MCP invocation under on-behalf-of identity;
  • Databricks App health, Lakebase-backed stop/start recovery, hook-authored dynamic-agent continuity, cascade deletion, burst-load bounds, and two-user isolation.

The same 7.0.2 record also passed configured Tier O probes for Unity Catalog Agent Services registration, MLflow ResponsesAgent, managed RAG evaluation, AI Search, Genie Agent Mode, Feature Serving, Jobs, Lakeflow, and a classic notebook. Agent Services runtime invocation was not available, so the record establishes registration lifecycle behavior but not invocation through that preview.

The same-package Tier A record passed approval provenance plus create, verify, mutate, delete, and verify-delete lifecycles for serverless Jobs, Lakeflow, direct-vector AI Search, custom-model Serving, Unity Catalog administration under OBO, Workspace objects, secret references, and Genie Agents. Every lifecycle ended with cleanupRequired: false; the pre-run and post-run sweepers found no retained certification resources.

Capability status

Live-certified

  • Core consumption path: Required Tier R checks passed in the recorded Azure workspace.
  • Databricks App restart recovery: Durable state, stream offsets, approvals, and deletion behavior passed stop/start probes.
  • Databricks App identity isolation: Two distinct users could access only their own runs; direct cross-user reads returned 404, and responses contained no secrets.

Beta and workspace-dependent

  • MLflow ResponsesAgent — passed Tier O: The Responses schema, stable streamed output item, inference tables, and secure App proxy path passed in the current run.
  • Unity Catalog Agent Services — registration passed Tier O: Create, discover, update, govern, and delete passed; runtime invocation remains unavailable in the certified workspace.
  • Genie Agent Mode — passed Tier O: Ordered output and a terminal SSE event passed in the current run.
  • Managed RAG evaluation — passed Tier O: The configured MLflow 3 evaluation job completed successfully against the governed golden set.

Not established by this record

  • Optional authoring variants: The current Tier A record does not establish classic-compute Jobs, Delta Sync indexes, provisioned-throughput Serving, or Genie Agent Mode authoring.
  • Two-user App isolation rolling claim: The current run passed the two-user probe, but one run does not establish the separate 14-day rolling claim.
  • AWS and Google Cloud workspaces: This Azure record does not establish live behavior in another cloud or region.

Beta and workspace-dependent are textual status labels, not color-only indicators. Preview availability can differ by account, region, entitlement, and Databricks rollout.

A controlled single-user development or private evaluation can leave require_user_isolation disabled; that is the workflow default and does not require inventing a second user. Such a run may validate the configured single-user capabilities, but it cannot publish a changed Databricks package, certify a shared/user-facing App, or advance the public two-user rolling claim. Those claims continue to require two distinct identities and retained isolation evidence.

How certification is evaluated

The reference Databricks App is an on-demand certification target. The protected live workflow deploys and starts it for the bounded certification window, uploads the redacted evidence, and stops its compute in an unconditional cleanup step. A cleanup failure fails the workflow rather than leaving the App silently active. Operators should not keep the reference App running between certifications.

Fabric uses three evidence tiers:

  • Tier R — production consumption and runtime behavior: Every required check must pass before publishing a changed Databricks package.
  • Tier A — protected resource-authoring lifecycles: Required for management claims; cleanup must complete without leaked resources.
  • Tier O — preview, SKU-specific, or optional integrations: Recorded visibly but non-blocking unless explicitly promoted for that run.

The release workflow validates the protected run, commit, package digest, generated App digest, restart evidence, required results, and evidence age before publishing. Direct local publication of the Databricks package fails closed. An independently versioned, non-Databricks release scope may publish only its explicit package allowlist without a Databricks run; it cannot include, tag, or publish the Databricks candidate. This prevents pending Databricks source from blocking an unrelated connector release without weakening the Databricks gate.

What customers should verify

Before production rollout, run the documented preflight and smoke tests in the target workspace. Confirm:

  • the intended cloud and region expose Databricks Apps, Lakebase, Model Serving, and required AI services;
  • the application and user principals have only the necessary workspace and Unity Catalog grants;
  • on-behalf-of scopes are consented and resolve the expected user;
  • private networking, egress, and SQL policies match the deployment;
  • restart recovery and tenant isolation pass using representative identities;
  • Beta capabilities are enabled for the target workspace before relying on them.

Use workspace compatibility for API and runtime requirements, authoring certification for resource-management coverage, and ResponsesAgent for that Beta surface's specific contract and evidence.

Evidence references

  • Tier R consumption run: 31053240003
  • Tier A authoring run: 31056050505
  • Machine-readable public status
  • Source and protected-run access
  • Certified package: @fabric-harness/databricks@7.0.2
  • Tier R evidence: dbx-cert-40f9f87ecd2044f529d37e4dcbc260e55707cda9df5c987790078f35df29850a
  • Tier A evidence: dbx-cert-37f20b775f8f1e676f6b7d36bb17bb61f1ae9c593e560e028d1872764d70693d
  • Required results: 21 of 21 Tier R checks passed
  • Authoring results: 10 of 10 Tier A checks passed for the same package artifact