dbt: record the model run; bind the exported data.
A dbt model, manifest, and run result explain how warehouse relations were built. A recipient-verifiable handoff still needs a stable artifact representation whose exact bytes both sides can hash.
Implementation boundary. No dbt package, post-hook, or warehouse-export command ships with Makoto.
The attachment point
| Model materialization | Capture model unique ID, compiled SQL digest, invocation ID, adapter, relation, and test results after the materialization succeeds. |
|---|---|
| Exact artifact | Export a stable file set or create a deterministic manifest over the handed-off relation snapshot. A relation name alone is mutable. |
| Predecessors | Resolve exact upstream artifact and statement digests; do not equate the dbt DAG edge with a signed Makoto edge. |
| Project boundary | Create the signed handoff only when the exact output set and required private profiles are known. |
Control flow
dbt build --select curated_orders
# Export or manifest the exact relation snapshot being transferred.
# Then append one statement from a reviewed source checkout.
uv run makoto attest transform --help
uv run makoto handoff create --helpAn eventual package could read manifest.json and run_results.json for context. It still must own artifact resolution, key custody, predecessor lookup, deterministic retries, and receiver-visible failures.
What the evidence can say
It can bind a stable dbt-produced export to compiled-model context and exact predecessors. It cannot prove SQL semantics, regulatory compliance, or a warehouse relation’s future contents.
Contribute one materialization-to-export case.
The test should identify exact bytes, preserve dbt context, and fail when the exported snapshot changes after signing.