One signed claim per event. One verifiable history at handoff.
Makoto is a source-first protocol for data provenance. It records an origin, appends independently signed transformation statements, lets data teams attach private JSON Schema rules by digest, and gives the recipient enough evidence to verify the history and the bytes it actually received.
Publication status. The normative text and implementation are available for public review. They are not yet an immutable tagged release.
The record has four parts
- OriginThe first producer states where and how the data was collected and binds that claim to one or more exact artifact digests. An origin has no predecessor.
- TransformationsEvery later producer creates a new statement. It names the exact predecessor payload and exact input artifact, describes the operation, and binds any outputs. Earlier statements are never edited.
- AttestationsEach statement is carried in a DSSE envelope. Signatures authenticate exact payload bytes; receiver-owned policy separately decides whether those keys were authorized for those claims.
- HandoffThe sender signs the exact statement set, roots, heads, final artifacts, recipients, and required profiles being transferred. That commitment lets a receiver distinguish a complete handoff from a merely continuous fragment.
Core objects and their jobs
| Object | What it commits to | What remains outside it |
|---|---|---|
| Origin statement | Source claims, event identity and time, and exact observed subjects. | Whether the source claim is truthful. |
| Transformation statement | Operation metadata, predecessor payloads, input artifacts, and output subjects. | Proof that the claimed code actually executed. |
| DSSE envelope | The exact statement payload and one or more cryptographic signatures. | Authorization to make the claim. |
| Profile reference | A public or private JSON Schema root and its complete digest-pinned closure. | Ambient network retrieval or producer-controlled policy. |
| Handoff manifest | The exact evidence and artifacts intentionally transferred to named recipients. | Independent freshness expectations. |
| Trust policy | Which keys may make which claims, under which thresholds and resource limits. | It is supplied by the receiver, not trusted from the bundle. |
| Verification report | Separate outcomes for structure, cryptography, authorization, profiles, graph, handoff, freshness, and artifacts. | A single marketing-grade “trusted” badge. |
A small core; private rules without a fork
Core schemas close the portable protocol shapes. Organization-specific claims do not require a central registry or a public schema. A team can publish a profile, keep it on an authenticated internal catalog, or never publish it at all. The signed statement carries the profile URI plus the exact root and closure digests, so the receiver can resolve the bytes it has already authorized without trusting a live network lookup.
Profiles can constrain transformation metadata and, for supported structured artifacts, the artifact content itself: required fields, identifier formats, control characters, enumerated classifications, bounded string patterns, or the absence of disallowed fields. Passing a profile proves only that the inspected JSON matches those rules. It does not make the content truthful, safe, confidential, or legally compliant.
Verification is deliberately decomposed
| Question | Required evidence | Why it stays separate |
|---|---|---|
| Is the resource well-formed? | Core schema and any required profile pass. | Valid structure says nothing about identity. |
| Who controlled the signing key? | DSSE signature verifies over exact payload bytes. | A valid signature may belong to the wrong party. |
| Was that signer allowed? | Receiver policy authorizes the key for the selected claim and role. | Authorization is a consumer decision. |
| Does the history connect? | Every transformation resolves exact predecessor and artifact digests back to an origin. | Continuity does not prove that no branch was withheld. |
| Is this the complete handoff? | An authorized signed manifest commits to exact roots, heads, statements, profiles, and final artifacts. | An older complete handoff can still be replayed. |
| Are these the expected bytes? | Independent expected manifest, head, nonce, age, or artifact constraints; plus a digest of the bytes received. | Freshness and received-byte integrity are distinct. |
Normative resources
The hosted schema catalog exposes the exact machine-readable resources. The complete normative text fixes algorithms, limits, diagnostics, and conformance fixtures. The runnable proof exercises an allowed handoff and seven deterministic denials against the pinned reference implementation.
What Makoto does not claim
Makoto does not certify a source as truthful, prove that transformation code ran, establish data quality, prevent disclosure, grant legal compliance, or discover copies that nobody recorded. Hardware-backed keys, software-build provenance, transparency logs, access control, semantic catalogs, and pipeline observability can complement the protocol; none is silently implied by a passing Makoto report.
Challenge the protocol with an actual handoff.
Bring a source, two transformations, a private rule, a signer boundary, and a receiving decision. The useful contribution is the smallest case that exposes an ambiguity or produces a new conformance fixture.