Know where data began, what changed, and who attested to it.
Makoto is a source-first, SLSA-like framework for data. It keeps a verifiable history beside the bytes as data moves between systems, teams, and organizations.
-
1 The gate you add
- name: Verify the received bundle id: verify shell: bash env: HANDOFF: ${{ matrix.handoff }} EXPECTED_MANIFEST: ${{ matrix.manifest }} EXPECTED_HEAD: ${{ matrix.head }} run: | verify() { uv run --project .makoto-core makoto verify bundle "handoffs/$HANDOFF/bundle" \ --policy receiver/policy.json \ --schema-catalog receiver/catalog.json \ --expected-manifest "$EXPECTED_MANIFEST" \ --expected-head "$EXPECTED_HEAD" \ --expected-artifact "receiver/expected/$HANDOFF.artifact.json" \ --evaluation-time "$EVALUATION_TIME" "$@" } status=0 verify --json > makoto-report.json || status=$? verify || true exit "$status"The receiver's CI gate, quoted from demos/01/makoto-gate.yml. The load job declaresneeds: gate, so nothing loads until Makoto allows the exact bytes that arrived. -
2 What it catches
$ makoto verify bundle handoffs/mutated-final-data/bundle \ --policy receiver/policy.json \ --schema-catalog receiver/catalog.json \ --expected-manifest sha256:e24aae77ba1374162edff49aa0ab1d8dd7e38c333e134a2128ad1598fec99fb7 \ --expected-head sha256:99aee76db46a720405da6d0015d427c791b0d4e02367b9e2bc36ce82ae812bce \ --expected-artifact receiver/expected/mutated-final-data.artifact.json \ --evaluation-time 2026-09-16T16:00:00Z PASS load-safely PASS parse-strictly PASS index-payloads PASS core-schemas PASS signatures PASS authorization-thresholds PASS metadata-profiles PASS authorization PASS graph-dependency-artifacts PASS graph PASS roots-and-heads PASS completeness-anchor PASS freshness-anchors FAIL artifact-bytes PASS artifact-profiles PASS decision DENY decision manifest sha256:e24aae77ba1374162edff49aa0ab1d8dd7e38c333e134a2128ad1598fec99fb7 E_ARTIFACT_DIGEST: final artifact bytes differ from the signed digest $ echo $? 1Captured output from the poisoned-pipeline case: one byte appended after signing. Every signature still verifies; artifact-bytesfails and the job exits 1.
Data does not need another catalog entry. It needs evidence that survives the handoff.
The hard part is not identifying one source file. It is keeping origin, processing history, attesters, and exact artifacts connected after the file becomes ten copies across systems, teams, vendors, and forgotten exports. See why lineage matters.
Three questions, one signed history
- Where did this data begin?An origin statement binds claims about collection and source to exact artifact bytes.
- What happened along the way?Each transformation points to predecessor statements and artifacts. History grows by addition, never by rewriting an earlier claim.
- Who stands behind each claim?Signatures prove control of keys. The receiver separately decides whether those keys were authorized for the claims they signed.
- Are these still the same bytes?Digests bind the signed history to the source, intermediate artifacts when available, and the final data delivered to the receiver.
What the protocol carries
| Evidence | What it answers | Who decides |
|---|---|---|
| Origin statement | Where and how the data began | The producer states it; the receiver evaluates it |
| Transformation graph | Which exact inputs and steps produced this artifact | Each participating system appends its claim |
| DSSE signatures | Which keys attested to each statement | The receiver authorizes or rejects the signers |
| JSON Schema profiles | Which public or private structural rules apply | Data teams define them; receivers resolve exact digests |
| Artifact digests | Whether the delivered bytes match the signed handoff | The receiver hashes the bytes it actually received |
Real failures, not toy metadata
- 01
Independent data handoff
A producer signs an origin and two transformations. A receiver applies its own trust policy and verifies the final bytes.
Run it → - 02
Poisoned pipeline
Trace malicious or corrupted input through the transformations that spread it.
Read the case → - 03
Scientific reproducibility
Preserve the source and processing evidence needed to reproduce a published result.
Read the case → - 04
Release provenance
Bind a published dataset to its inputs, build history, signed handoff, and exact release bytes.
Read the case → - 05
Configuration postmortem
Reconstruct which configuration and processing step altered downstream data and where it propagated.
Read the case → - 06
AI dataset verification
Refuse training data unless its source, processing claims, authorized signers, profiles, and bytes verify.
Read the case → - 07
Invisible Unicode
Make a policy-relevant normalization or rejection step explicit when hidden characters alter meaning.
Read the case →
One protocol, many implementation paths
| Reference implementation | Create, sign, bundle, and verify evidence locally from the open-source core repository. | Open core repository ↗ |
|---|---|---|
| Hosted JSON Schemas | Validate core statements and resolve exact digest-pinned private profiles. | Open schema catalog |
| Integration patterns | Attach evidence at lifecycle hooks, materializations, writes, releases, and organizational handoffs. | Explore integrations |
A common language should be built by the people who need it.
The protocol, schemas, verifier, conformance fixtures, demos, and site are open on GitHub. Bring a real handoff, challenge a claim, add a denial case, or send a tested patch.