Databricks application-kit commands

Use fa application-kit when a migration or Databricks-native modernization should produce an operational application, not only tables, pipelines, and dashboards. Airlift turns the opportunity into a typed delivery and evidence contract. It does not generate a success claim from a checklist and it does not deploy the release.

An application kit has two layers:

• a shared foundation: Databricks Apps, Lakebase, Unity Catalog, portable runtime bindings, an immutable release intent, an isolated preview, and a restore rehearsal;
• one or more domain modules: schemas, grants, synthetic fixtures, BDD scenarios, and module-specific evidence requirements.

List available modules

fa application-kit module list
fa application-kit module list --json

Initialize a manifest

fa application-kit init \
  --name "Customer operations" \
  --module customer_intelligence \
  --cloud azure \
  > application-kit.json

--cloud accepts aws, azure, or gcp. The generated manifest uses logical resource names and opaque references. It never contains a workspace ID, database connection string, token, or secret value. Every Databricks App runs with a dedicated service principal whose grants are resolved per environment.

The generated foundation includes:

{
  "foundation": {
    "databricksApp": true,
    "lakebase": true,
    "unityCatalog": true,
    "declarativeAutomationBundle": true,
    "dedicatedServicePrincipal": true,
    "runtimeBindings": [
      {
        "name": "application-state",
        "resourceType": "lakebase",
        "permission": "write",
        "required": true,
        "source": "valueFrom"
      },
      {
        "name": "governed-data",
        "resourceType": "unity_catalog_schema",
        "permission": "read",
        "required": true,
        "source": "valueFrom"
      }
    ],
    "syncedTables": [],
    "preview": {
      "isolatedBranch": true,
      "restoreRequired": true,
      "rehearsalRequired": true
    }
  }
}

Add Synced Table contracts when application serving needs governed lakehouse data in Lakebase. Each row declares a direction, opaque source and target references, business keys, and a freshness SLO. Airlift records the requirement; the admitted Databricks adapter and release own materialization.

Inspect and plan

fa application-kit validate --file application-kit.json
fa application-kit inspect --file application-kit.json
fa application-kit plan \
  --file application-kit.json \
  --json > application-plan.json

The plan is deterministic. It expands each module into required BDD and assurance scenarios and produces explicit handoffs:

• Fabric Platform: governed application mutations and audit;
• Fabric Harness: bounded agent execution and Databricks transport;
• Fabric Experiments: BDD, A/B, performance, quality, and agent/model evaluations;
• Fabric Runway: bundle validation, preview, deployment, promotion, and rollback;
• Fabric Radar: SLO and operational evidence;
• Fabric Tower: work references only; and
• Fabric Airlift: application-modernization scope, requirements, and evidence decision.

The plan contains deploymentCli: "fr". There is deliberately no fa application-kit deploy command.

Qualify evidence

Without evidence, only the contract can be proven:

fa application-kit qualify \
  --file application-plan.json \
  --level contract_only

Hermetic qualification requires a passing bundle-validation reference, secret scan, synthetic-fixture digest, BDD contract, and every required runtime binding:

fa application-kit qualify \
  --file application-plan.json \
  --evidence application-evidence.json \
  --level hermetic_proven

Workspace qualification additionally requires:

• a successful Runway deployment for the qualified artifact digest;
• a passing Experiments execution for that same artifact digest;
• an isolated branch preview and tested restore reference; and
• a healthy Radar observation when the plan declares an operational SLO.

fa application-kit qualify \
  --file application-plan.json \
  --evidence application-evidence.json \
  --level workspace_proven \
  --json > application-qualification.json

Digest drift, failed scenarios, missing bindings, or missing required operational evidence blocks. Airlift stores only provider references and digests; it does not copy the provider's release, test, or monitoring state.

Register the immutable plan

fa application-kit register \
  --file application-plan.json \
  --engagement-id <engagement-id> \
  --estate-id <estate-id> \
  --artifact-id <immutable-artifact-reference> \
  --idempotency-key <stable-key>

Registration invokes governed airlift.artifact_register with media type application/vnd.fabric.airlift.application-kit+json. Store the plan body in an admitted immutable artifact location; Airlift records its reference, digest, producer, and audit event.

Query only registered application-kit artifacts without filtering the general artifact ledger yourself:

fa application-kit list --engagement-id <engagement-id>
fa application-kit show <artifact-id> --json

module list is the only module-discovery spelling. Generate the complete current command surface with fa commands --json.

Execute through the owning products

fr validate --dir generated
fr deploy --dir generated --environment preview

fx apply experiments/
fx report <experiment-or-suite-id>

Use Runway for deploy, promote, and rollback. Use Experiments for executable BDD, A/B, performance, and quality evidence. Application-kit qualification is a read-only Airlift decision over those foreign results.

See Operational application modernization for the complete developer lifecycle and proof model.