Run Compute over a Databricks Delta table version

What this connects

Delta tables you already govern, in one direction. Lithi reads a table version you froze, and writes an accepted result bundle that you load back yourself.

The conformance level is import_compatible: Lithi reads released open table and file formats, and the named level comes with a published conformance matrix. That is not a Databricks API, and Lithi never signs in to your workspace.

Bind an exact input

A Delta table names its own versions, so bind that identity rather than a path.

Materialize the rows at one table version into a location you govern, then pin the bytes you wrote:

"input": {
  "adapter": "<your registered storage adapter>",
  "location": "<the export you just wrote>",
  "credential_ref": "<a registered credential reference>",
  "snapshot": {
    "version_id": "<the Delta table version you exported>",
    "content_sha256": "<the digest of those exact bytes>"
  },
  "format": "<a released format profile>",
  "item_id_field": "<the column that identifies a row>"
}

Keep the exported schema beside the version number. A later table version can add, drop or retype a column, and the digest is what makes that visible rather than silent. See how to pin a snapshot that cannot change.

Credentials

credential_ref carries a reference to a credential you registered, never a secret. Register it, test it, read it back, and revoke it when the work ends.

Your warehouse credentials stay in your workspace. A work request carries no personal access token, password or connection string, and none reaches a job, a receipt or a result file.

Formats and limits

Name the profile in input.format. The released profile decides how nulls, decimals, timestamps and nested fields are read, not the writer that produced the export.

The maximum item count is stated on the workflow descriptor and repeated on your quote. Your own limits object carries deadline and maximum_price.

Commit the output

Accepted rows land in data/part-*, with the namespaced columns lithi_status, lithi_result, lithi_error_code, lithi_confidence, lithi_evidence, lithi_verification and lithi_usage appended.

result-manifest.json is written last and is the only complete-bundle marker. Part files alone never mean the job finished.

Loading is a separate step that you run. Read the counts in the manifest, write a new table version from the accepted parts, then reconcile that version's row count against the manifest before anyone queries it.

What is not supported

Lithi makes no wire, SDK or endpoint compatibility claim for any Databricks service. Reading an open file format is not the same thing.

These are outside the adapter:

• Running notebooks, jobs or SQL in your workspace.
• Writing into your catalog on your behalf, or any path around your own storage governance.
• Live or streaming tables as an input. Freeze a version first.
• Passing a warehouse credential through a work request.

If the export moved after you quoted, admission answers REPLAN_REQUIRED. Re-export at a current table version, pin the new digest, quote again, then approve again. Approval is always its own act.