Databricks: bind a committed table version to exact handoff bytes.
Unity Catalog and Delta history supply useful operational context. They do not, by themselves, create a signed Makoto graph or prove which bytes a recipient received.
Implementation boundary. This is a candidate lifecycle boundary, not an automatic notebook hook, expectation, system-table mapping, or shipped adapter.
The attachment point
| Delta commit | After a write commits, record table identity, version, job, cluster, and notebook context. Resolve the exact snapshot files or a deterministic manifest. |
|---|---|
| Feature or model export | Attest the stable exported artifact; reference the upstream table statement and exact input digest. |
| Unity Catalog | Store pointers or searchable metadata if useful. Statement and artifact digests remain the portable identities. |
| External handoff | Sign the exact roots, heads, profiles, and final artifacts given to the recipient; keep receiver policy outside the bundle. |
Control flow
# The Databricks job commits a table version or export.
# A post-commit task resolves exact input and output identities,
# writes operation metadata, then calls the checked-out reference CLI.
uv run makoto attest transform --help
uv run makoto handoff create --helpThe integration must define what one artifact means: snapshot manifest, exported files, or another immutable representation. A table name and version are useful selectors, but they are not substitutes for the artifact digest a receiver verifies.
What the evidence can say
It can bind a Databricks commit or export to exact predecessor and output evidence. It cannot prove that every notebook cell ran, that a quality expectation was correct, or that a model card automatically carries the data history.
Choose one Databricks boundary and make it exact.
Contribute a tested Delta snapshot or export fixture, including the failure when a file set and claimed table version diverge.