One signed claim per event. One verifiable history at handoff.

Read the normative text

Everything below this section is orientation. The obligations themselves — encodings, digest and signature rules, the statement model, profile resolution limits, the handoff anchor, the trust-policy grammar, the ordered verification algorithm, and every diagnostic code — are fixed in one document, reproduced in full at the normative text and served raw at /spec/v0.2/spec.md.

The record has four parts

1. 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.
2. 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.
3. 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.
4. 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.

What one record actually looks like

This is the origin statement from the runnable proof, decoded from the signed envelope that ships in the bundle. It is not an illustration written for this page: the digest below is the one the verifier recomputes, and the same bytes are what the transformation that follows names as its predecessor.

{
  "_type": "https://in-toto.io/Statement/v1",
  "predicate": {
    "event": {
      "id": "urn:uuid:11111111-1111-4111-8111-111111111111",
      "occurredAt": "2026-09-16T16:00:00Z"
    },
    "profiles": [],
    "schemaVersion": "0.2",
    "source": {
      "kind": "urn:makoto:demo:source:synthetic-file",
      "uri": "urn:makoto:demo:v0.2:source:customers-raw"
    }
  },
  "predicateType": "https://usemakoto.dev/predicate/v0.2/origin",
  "subject": [
    {
      "digest": {
        "sha256": "4e90181e7f75ccdf0e4d81c83d281f53806bed241787cdc751e22b2d4cd19919"
      },
      "name": "customers.raw.json"
    }
  ]
}

The envelope around it carries the signature. A signature authenticates these exact payload bytes and says nothing about whether that signer was allowed to make this claim — that is the receiver's policy decision, kept deliberately separate.

Core objects and their jobs

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

Read the assurance model · Follow the verification sequence

Machine-readable resources

Thirteen resources are served at stable URLs and pinned by digest in the catalog. The schema index reproduces every one of them in full, next to its identifier and its catalog digest, so a claim on a page can be checked against the bytes a resolver will actually fetch. The release pointer resolves the name “latest” to the current catalog, as a convenience for people. It is not an immutable protocol identifier: it moves when a new version is published, so never cite it as a schema $id, a $schema, or a pinned reference. Pin the versioned resource and its digest instead.

The runnable proof exercises an allowed handoff and seven deterministic denials against the pinned reference implementation.

Versions

Each protocol version is a separate family of identifiers. Evidence keeps the version it was written in, and a verifier never mixes two families in one verification.

Assurance levels

Like SLSA, Makoto separates producer tracks from receiver results. The Origin and Transform tracks each define three cumulative levels a producer adopts one step at a time; what a receiver established about one handoff is a separate verified property, carried in a standard SLSA Verification Summary Attestation. Neither is an allow/deny score or a correctness claim.

The verified properties are MAKOTO_AUTHORIZED, MAKOTO_GRAPH_COMPLETE, MAKOTO_FRESHNESS_ANCHORED, MAKOTO_SCHEMA_CONFORMANT, and MAKOTO_REPRODUCED. Read the assurance model for each level's evidence and each property's exact issuance rule, or Section 8 for the normative text.

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.