Fabric Platform governance

@fabric-harness/databricks is the Fabric family's production Databricks integration. Vertical applications import it; they do not implement workspace authentication, generic service clients, Lakebase credential exchange, or retry and polling behavior locally.

Fabric Platform owns the business mutation, policy decision, HITL approval, and durable audit ledger. Harness owns Databricks execution and returns technical evidence to the Platform invocation.

import { createDatabricksMutationGovernanceResolver } from
  "@fabric-harness/databricks/platform";

const resolveMutationGovernance = createDatabricksMutationGovernanceResolver({
  workspaceHost: process.env.DATABRICKS_HOST!,
  principal,
  resolveResources: ({ parameters }) => [{
    resourceType: "unity-catalog-table",
    resourceId: String((parameters as { table: string }).table),
    operation: "update",
    dataClassifications: ["customer-data"],
  }],
});

The resolver produces a provider-neutral MutationFootprint and an ExecutionPrincipal containing the Databricks identity and its initiating actor. Tokens and client secrets are never represented.

Use databricksExecutionAttestation() after SQL, Jobs, Lakeflow, Serving, MLflow, deployment, or other external work. Its statement ID, run ID, request ID, trace ID, deployment ID, or digest becomes an external evidence reference and can satisfy a named Platform policy obligation.

There is only one business approval queue. Harness capability enforcement is defense in depth and must not create an unrelated approval record for a Platform mutation.

Governance descriptors on config.tools

databricks({ tools: [...] }) accepts your own ToolDefs. Any entry whose metadata.effect is 'write' or 'execute' must declare metadata.governance.resources, naming the resources the call touches. A tool that omits it fails at bundle construction:

databricks governance: authoring tool "databricks_run_job" must declare metadata.governance.resources.

This is what lets approval, capability enforcement, and the lineage record identify the target without guessing from the input shape. The run-job tool is the worked example:

metadata: {
  effect: 'execute',
  provider: 'databricks',
  service: 'jobs',
  governance: { resources: [{ kind: 'job', path: '/jobId' }] },
},

Each descriptor is:

A descriptor path needs a corresponding inputSchema property. Pinning that property with const or enum — as the bounded run-job tool does — does not affect pointer validation.