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. |
SLSA and Makoto, concept by concept
Makoto is a sibling of SLSA, not an extension of it. SLSA secures how software is built; Makoto records and verifies how data moved from its first observation to a recipient. Both express provenance as in-toto Statements in DSSE envelopes, so the same storage and signature tooling can carry both.
| SLSA concept | Makoto counterpart | Key difference |
|---|---|---|
| Software artifact | Data artifact, or a dataset manifest over partitions | A directory or table is not a byte sequence, so it is named through exact subjects or a manifest of entry digests. |
| Build | Transformation statement | Data passes through many stages; each appends its own signed statement instead of one build record. |
| Source | Origin statement | Data sources are sensors, APIs, exports, and people, not only repositories. |
| Build provenance | Origin plus transformation statements, anchored by a signed handoff | Completeness needs an explicit handoff that commits to the exact graph sent. |
| Builder identity | Collector and executor keys, authorized per role by receiver policy | Ingestion and processing identities are separated, and the receiver decides what each may sign. |
Why data needs its own contract
| Dimension | Software (SLSA) | Data (Makoto) |
|---|---|---|
| Transformations | Usually one build step | Multi-stage pipelines, each step bound to exact predecessor bytes |
| Granularity | File or package | File, partition, or dataset manifest |
| Privacy | Metadata is usually public | Metadata and content can contain personal data; private profiles stay with the receiver |
| Lineage depth | Source to binary | Source through any number of transformations to a handoff |
| Reproducibility | Often reproducible | Often time-dependent, so exact bytes must be recorded when they exist |
| Content hazards | Malicious code paths | Unchanged bytes that break receiver rules, such as reintroduced identifiers or invisible Unicode |
Levels side by side
Makoto follows SLSA's structure. Tracks describe producer controls that can be adopted one level at a time, and a Verification Summary Attestation records what a receiver established about one handoff. Makoto's Transform track has the same shape as SLSA's build track, applied to data transformations; its Origin track grades the process that first captures data.
| Level | SLSA build track | Makoto Transform track | Makoto Origin track |
|---|---|---|---|
| L1 | Provenance exists showing how the package was built. | Traceable execution: every step binds exact inputs, predecessors, operation identity, and outputs. | Traceable capture: the first observed bytes have origin evidence. |
| L2 | Signed provenance generated by a hosted build platform. | Platform-authenticated execution: a hosted pipeline generates and signs the evidence. | Platform-authenticated capture: a hosted capture platform generates and signs that evidence. |
| L3 | A hardened build platform with strong isolation between builds. | Hardened execution: isolated, ephemeral runs protect both execution and signing from user-controlled steps. | Policy-controlled capture: the platform continuously enforces declared capture controls. |
Origin L3 is analogous to SLSA Source L3: evidence that declared organizational controls were enforced. Receiver results stay out of the tracks and are reported as verified properties such as MAKOTO_AUTHORIZED and MAKOTO_GRAPH_COMPLETE, in the standard SLSA VSA format. Makoto's identifiers deliberately do not begin with SLSA_. See the assurance model.
Predicate types side by side
| Framework | Predicate type |
|---|---|
| SLSA build provenance | https://slsa.dev/provenance/v1 |
| Makoto origin | https://usemakoto.dev/predicate/v0.2/origin |
| Makoto transformation | https://usemakoto.dev/predicate/v0.2/transform |
See a real signed origin envelope and its decoded statement.
When to use each
| Use SLSA for | Container images, published packages, compiled binaries, CI/CD build outputs, and infrastructure-as-code artifacts. |
|---|---|
| Use Makoto for | ETL outputs, machine-learning training and evaluation datasets, warehouse extracts, analytics and reporting data, and any data handed across a trust boundary. |
| Use both when | A machine-learning pipeline needs SLSA and an SBOM for training code and containers, Makoto for training, evaluation, and inference data, and separate signed records for the model digest, runtime configuration, and evaluation history. Bind them to one run identifier. Each record proves its own layer; none of them alone guarantees the model is reproducible. |
Compare the threat lists in the threat model.
Bring a workflow where the division is unclear.
The best comparison is an actual producer, transformation, artifact, and recipient, not a checkbox matrix.