These frameworks overlap. They are not interchangeable.
The useful question is not which acronym wins. It is whether you need software-build provenance, operational lineage, a semantic provenance graph, or a signed source-to-handoff data history that a recipient can verify independently.
| Framework | Primary question | Native strength | Where Makoto differs |
|---|---|---|---|
| SLSA | How was this software artifact built? | Build provenance, builder identity, dependency and build-system controls. | Makoto follows data from its first observation through mutable pipelines and organizational handoffs. |
| OpenLineage | What jobs and datasets participated in this run? | Operational events, job/run facets, dataset discovery, observability integrations. | Makoto binds exact artifacts and predecessor statements, signs claims, and lets the receiver apply independent authorization and completeness policy. |
| W3C PROV | How can provenance entities, activities, and agents be represented semantically? | Rich, interoperable provenance modeling and query. | Makoto defines a narrower operational evidence and verification contract around exact bytes, signatures, handoffs, and JSON Schema profiles. |
| Makoto | Can this recipient verify where these data bytes began, what signed steps led here, and who was authorized to attest them? | Source-first signed statements, hash-linked graph, digest-pinned profiles, signed handoff, and received-byte verification. | It does not replace pipeline observability, semantic provenance modeling, or software-build controls. |
How they can work together
- OpenLineage supplies contextJob names, runs, inputs, outputs, and facets can populate operation metadata. The adapter still resolves exact artifacts and Makoto predecessor bindings.
- W3C PROV supplies a semantic viewA system can map verified Makoto statements into PROV entities and activities for discovery without treating the semantic graph as the signed payload.
- SLSA covers code productionA transformation statement can reference the SLSA provenance of the software that performed the work. That connects software evidence to data evidence without collapsing them.
- Receiver policy composes the resultThe recipient decides which evidence is required, which identities are authorized, and which expected head, manifest, or artifact makes the handoff current.
A practical decision rule
| You need pipeline operations and impact analysis | Start with OpenLineage; add Makoto where data crosses a trust boundary or exact bytes must be verified. |
|---|---|
| You need semantic provenance exchange | Start with W3C PROV; use Makoto for the signed operational evidence underneath selected claims. |
| You need software build integrity | Use SLSA for the software artifact; reference that evidence from the data transformation claim. |
| You need recipient-verifiable data handoff | Use Makoto, plus whichever operational or semantic system supplies useful context. |
Bring a workflow where the division is unclear.
The best comparison is an actual producer, transformation, artifact, and recipient, not a checkbox matrix.