Expanso: attest where the data is read and where the result leaves.
Data-local execution can reduce movement, but locality alone is not provenance. A Makoto integration would bind exact local inputs, the signed predecessor graph, the operation performed, and the exact output crossing the next boundary.
Implementation boundary. This page describes a possible integration. It does not claim a shipped plugin, verified execution truth, or compliance certification.
The attachment point
| Local source read | Create or resolve an origin statement for the exact local artifact bytes before processing. |
|---|---|
| Job completion | After output commits, append a transformation statement with job, node, image, query, and execution context as operation metadata. |
| Distributed result | Use a dataset manifest when one logical result spans multiple nodes or files; preserve each exact member digest. |
| Outbound handoff | Sign the exact artifacts and evidence leaving the site; the receiver applies its own trust policy and profiles. |
Control flow
# A data-local job writes a stable result first.
# A post-job step resolves exact input and output artifacts.
uv run makoto attest transform --help
uv run makoto handoff create --help
# The recipient verifies outside the producer environment.
uv run makoto verify bundle --helpThe adapter would need explicit key custody per site, deterministic retry behavior, artifact identity across distributed outputs, and a transport for the signed handoff. A product job ID or log entry is useful context, not the portable artifact identity.
What the evidence can say
It can bind a data-local result to exact inputs, an operation claim, and the next handoff. It cannot prove HIPAA compliance, guarantee the claimed computation ran, or make location metadata confidential.
Start with one site-to-recipient handoff.
Contribute a fixture with an exact local input, distributed or single-file output, signer policy, and independent byte verification.