Two tracks for how evidence was made. Five properties for what a receiver verified.

The model at a glance

Origin answers whether the data was captured under a known process. Transform answers whether its processing history was produced under a known execution process. Receiver results answer different questions: whether this handoff is authorized, graph-complete, schema-conformant, fresh, or reproduced.

No third track is needed. Transport integrity, authorization, completeness, freshness, schema conformance, privacy rules, and reproducibility are properties of a particular verification or policy, not independently adoptable producer processes.

How levels are counted

• Cumulative within a track. Each level includes everything below it.
• The weakest step sets the level. The level for a final artifact is the minimum qualified level among all reachable statements in that track.
• Absence is not promoted. A graph with no transformation has no Transform level; it is reported as UNEVALUATED, never silently as L1.
• A level names its authority. Receivers may accept or reject the authority that issued a level, but accepting a different trust root never recalculates the producer's level from unrelated bundle checks. The accepted level always names its assessment policy and issuer.
• Not an allow/deny score. A track level is never derived by grouping arbitrary receiver checks.

The stable identifiers are MAKOTO_ORIGIN_LEVEL_1, MAKOTO_ORIGIN_LEVEL_2, MAKOTO_ORIGIN_LEVEL_3, MAKOTO_TRANSFORM_LEVEL_1, MAKOTO_TRANSFORM_LEVEL_2, and MAKOTO_TRANSFORM_LEVEL_3, plus MAKOTO_ORIGIN_LEVEL_UNEVALUATED and MAKOTO_TRANSFORM_LEVEL_UNEVALUATED when no claim is made. They deliberately do not begin with SLSA_, which SLSA reserves for its own results.

Origin track

The Origin track grades the process that first captures data into a Makoto graph. It does not ask Salesforce, a partner API, or a sensor to adopt Makoto. The adopting producer is the collector or capture platform that observes that external source.

Origin L1 · Traceable capture

Origin L2 · Platform-authenticated capture

Origin L3 · Policy-controlled capture

Origin L3 is analogous to SLSA Source L3: it provides evidence that declared organizational controls were enforced. It does not establish that a sensor reading was physically true or that an authorized collector was honest. The reference profile below is one standard control set for it.

Transform track

The Transform track grades the platform controls under which data transformations run and their provenance is produced.

Transform L1 · Traceable execution

Transform L2 · Platform-authenticated execution

Transform L3 · Hardened execution

Makoto does not define a hardware-attestation wire format. Transform L3 defines the control outcome and uses the same delegation model as a SLSA VSA: a receiver trusts a named verifier under an exact assessment policy. A trusted Transform L3 assessment carries at least one raw hardware-evidence descriptor, only the evidence URI and SHA-256 digest, in its standard inputAttestations. Which TPM, TEE, confidential-computing, or cloud-attestation evidence to accept is an open question, and implementations must not advertise raw hardware verification they do not perform.

Verified properties

Track levels deliberately do not absorb receiver outcomes. Each property below is issued only when its exact rule passes against a schema-valid Makoto verification report and the exact consumer policy it names.

MAKOTO_AUTHORIZED

MAKOTO_GRAPH_COMPLETE

This is the one property beyond the four motivating examples. Lineage falsification and branch omission are receiver-established results, but neither is an Origin or Transform platform level, and none of the other properties says the presented graph is complete.

MAKOTO_FRESHNESS_ANCHORED

MAKOTO_SCHEMA_CONFORMANT

MAKOTO_REPRODUCED

The verification summary

Makoto reuses the SLSA v1 Verification Summary Attestation instead of inventing a second summary envelope. It is an in-toto Statement v1 in DSSE whose predicateType is exactly https://slsa.dev/verification_summary/v1:

• subject holds the final artifact names and digests summarized.
• verifier, timeVerified, resourceUri, policy, inputAttestations, verificationResult, verifiedLevels, dependencyLevels, and slsaVersion keep their SLSA meanings; slsaVersion is 1.2.
• verifiedLevels contains at most one highest value for each Makoto track plus every verified property whose exact rule passed.
• verificationResult is PASSED only when the report decision is allow and every level or property the summary policy requires was established. Otherwise it is FAILED and verifiedLevels holds only FAILED; the optional evaluation sidecar keeps any individually established levels, properties, and diagnostics.

A receiver accepts a VSA only after validating the DSSE signature, exact subjects, expected resourceUri, configured verifier ID and key, exact policy URI and digest, verificationResult: PASSED, required level and property identifiers, and every locally required input-attestation digest. This is a closed boolean procedure, not an opaque score. A consumer that needs the detailed reasoning keeps or recomputes the underlying report.

The statement, handoff, bundle, and verification-report wire formats do not change. The receiver supplies its VSA trust inputs in the existing trust policy's optional verificationSummary member: the resource URI, the exact summary-policy descriptor, the required levels and properties, and each trusted verifier's key IDs, verifier ID, accepted assessment policy, allowed level claims, required evidence, and independence group. There is no second policy file.

Summarize a verification

These are the reference CLI's flags at the pinned core commit. makoto vsa assess is what a capture platform or pipeline runs to issue an L2 or L3 assessment; makoto vsa summarize is what a receiver or delegated verifier runs over a completed report. summarize exits 1 when the summary does not pass.

# A platform assesses its own run at Transform L2.
makoto vsa assess \
  --track transform \
  --level 2 \
  --input-attestation bundle/attestations/<statement>.dsse.json \
  --verifier-id https://pipeline.example/makoto-assessor \
  --resource-uri https://pipeline.example/runs/1234 \
  --policy-uri https://pipeline.example/policies/transform-l2 \
  --policy-digest sha256:<assessment policy digest> \
  --key keys/assessor.private.pem \
  --out transform-l2.vsa.dsse.json

# The receiver summarizes one verified handoff.
makoto vsa summarize \
  --report report.json \
  --attestations bundle/attestations \
  --policy receiver/policy.json \
  --assessment transform-l2.vsa.dsse.json \
  --verifier-id https://verifier.example/makoto \
  --key keys/verifier.private.pem \
  --evaluation-out summary-evaluation.json \
  --out summary.vsa.dsse.json

The report's policyDigest must equal the digest of the policy passed to summarize, and that policy must carry a verificationSummary member. The summary evaluator has its own closed diagnostic vocabulary, reported in the evaluation sidecar and never replacing the more specific bundle diagnostics: E_ORIGIN_LEVEL_1 through E_ORIGIN_LEVEL_3, E_TRANSFORM_LEVEL_1 through E_TRANSFORM_LEVEL_3, E_ASSESSMENT_TRUST, E_ASSESSMENT_SIGNATURE, E_ORIGIN_ASSESSMENT_SUBJECTS, E_ORIGIN_ASSESSMENT_INPUTS, E_TRANSFORM_ASSESSMENT_SUBJECTS, E_TRANSFORM_ASSESSMENT_INPUTS, E_PROPERTY_AUTHORIZED, E_PROPERTY_GRAPH_COMPLETE, E_PROPERTY_FRESHNESS_ANCHORED, E_PROPERTY_SCHEMA_CONFORMANT, E_PROPERTY_REPRODUCED, E_REQUIRED_VERIFICATION_RESULT, and E_REPORT_DENIED.

The Origin L3 reference profile

Core ships one standard reference profile for policy-controlled capture, origin-l3-reference-v1. Applied to an origin predicate, it requires a source record or device identifier, an ingestion timestamp, a run identifier, a non-null approver, and a freshness SLO. It is an example control set, not a universal core schema: producers pin its exact root and closure digests in an ordinary profile reference, receivers list that reference in the trusted Origin L3 assessor rule, and an organization may use a stricter private profile instead.

{
  "$schema": "https://usemakoto.dev/schema/v0.2/profile-dialect.schema.json",
  "$id": "https://usemakoto.dev/profiles/v0.2/origin-l3-reference-v1.schema.json",
  "title": "Makoto Origin L3 reference capture controls",
  "type": "object",
  "required": ["event", "source", "extensions"],
  "properties": {
    "event": {
      "type": "object",
      "required": ["occurredAt"]
    },
    "source": {
      "type": "object",
      "required": ["uri"]
    },
    "extensions": {
      "type": "object",
      "required": ["https://usemakoto.dev/profile/origin-l3/v1"],
      "properties": {
        "https://usemakoto.dev/profile/origin-l3/v1": {
          "type": "object",
          "required": [
            "sourceRecordOrDeviceId",
            "ingestedAt",
            "runId",
            "approver",
            "freshnessSloSeconds"
          ],
          "properties": {
            "sourceRecordOrDeviceId": { "type": "string", "minLength": 1 },
            "ingestedAt": { "type": "string", "minLength": 20, "maxLength": 30 },
            "runId": { "type": "string", "minLength": 1 },
            "approver": { "type": "string", "minLength": 1 },
            "freshnessSloSeconds": { "type": "integer", "minimum": 0 }
          },
          "additionalProperties": false
        }
      }
    }
  }
}

Its exact profile reference, which a producer pins and a receiver trusts:

{"closureDigest":{"sha256":"c02fed306cd6300d537c2664ad88b877dc5605b49b7d9dd0d03bf6c6332b6687"},"critical":true,"digest":{"sha256":"a6196356b740d8f7c72bce9093956c1e9457a8479a7b13269d00f9ff51af2f86"},"id":"https://usemakoto.dev/profiles/v0.2/origin-l3-reference-v1.schema.json","resources":[],"target":"predicate"}

Both are byte-for-byte the files in core docs/profiles/ at the pinned commit. The profile's $id is not served from this site yet: the hosted-schema release tooling mirrors only the core schema set, so resolve the profile from your local catalog by its digest, as every profile is resolved.

Seven checks behind every result

Levels and properties are built from seven separate answers a verifier gives. A report keeps all seven, so a receiver can always read past a summary to the evidence.

Adopting it step by step

1. Start at one source (Origin L1)Choose a real collection boundary and bind a signed origin claim to exact source bytes.
2. Append one transform (Transform L1)Make the next producer name its exact predecessor statement and input artifact instead of rewriting a shared history.
3. Separate the receiverMove trust policy, authorization rules, and schema catalogs outside the producer's bundle.
4. Sign the handoffCommit to the exact graph and artifacts intentionally transferred across the organizational boundary, and add private profiles for the rules that matter.
5. Anchor itPin the expected manifest, head, or artifact through an independent channel, or require a nonce or maximum age.
6. Move generation onto a platform (L2, then L3)Let a hosted capture platform or pipeline generate, sign, and assess the same evidence, then harden and isolate it.

Configuring the receiver

One stolen authorized key can sign accepted statements, and even an internally consistent graph. Defeating it also needs the receiver's expected values, or a threshold above one. Hardware-backed keys, transparency logs, access controls, and governance systems may strengthen a deployment; none is implied by a passing report.

What the evidence looks like

A signed origin statement from the reference handoff, decoded. It is Origin L1 evidence: it binds the exact source bytes by digest and names the source kind and URI that receiver rules match against.

{
  "_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"
    }
  ]
}

Output of jq -r .payload attestations/56b7be43….dsse.json | base64 -d | jq . on the published envelope.

The receiver side of the same boundary: the rule that authorizes that origin claim, which MAKOTO_AUTHORIZED reads, and the handoff expectations that make MAKOTO_FRESHNESS_ANCHORED possible.

{
  "rules": [
    {
      "authorizedKeyIds": [
        "sha256:fd110d301d2f077de1414b8f99f441b1403fab207b2052fbd2c065e4ee8e7dc2"
      ],
      "id": "urn:makoto:demo:rule:origin",
      "minimumSignatures": 1,
      "predicateTypes": [
        "https://usemakoto.dev/predicate/v0.2/origin"
      ],
      "sourceKinds": [
        "urn:makoto:demo:source:synthetic-file"
      ],
      "sourceUris": [
        "urn:makoto:demo:v0.2:source:customers-raw"
      ]
    }
  ],
  "handoff": {
    "allowReplayableHandoff": false,
    "authorizedKeyIds": [
      "sha256:d016df3d83373617c06b5e1d6359caa06eeba8b3af2c7077234f109f2194516c"
    ],
    "minimumSignatures": 1,
    "requireExpectedArtifacts": true,
    "requireExpectedHead": true,
    "requireExpectedManifest": true,
    "requireNonce": false,
    "requireRecipient": false
  }
}

Output of jq '{rules: [.rules[] | select(.id == "urn:makoto:demo:rule:origin")], handoff}' policy.json on the published receiver policy.

From L1 evidence to a verified handoff

These are the command shapes the reference end-to-end proof runs, with its paths shortened. Steps 1 and 2 produce Origin L1 and Transform L1 evidence from a developer machine; L2 and L3 need a hosted platform to generate, sign, and assess that same evidence, as above.

# 1. Origin L1: sign an origin claim over exact bytes.
makoto key generate --private-out keys/origin.private.pem --public-out keys/origin.public.pem
makoto attest origin \
  --subject customers.raw.json=data/customers.raw.json \
  --source-kind urn:makoto:demo:source:synthetic-file \
  --source-uri urn:makoto:demo:v0.2:source:customers-raw \
  --event-id urn:uuid:11111111-1111-4111-8111-111111111111 \
  --occurred-at 2026-09-16T16:00:00Z \
  --key keys/origin.private.pem \
  --out attestations/01-origin.dsse.json

# 2. Transform L1: append one step that binds its predecessor and input bytes.
makoto attest transform \
  --subject customers.normalized.json=data/customers.normalized.json \
  --input-binding bindings/normalize-input.json \
  --operation-type urn:makoto:demo:operation:normalize \
  --operation-name "Normalize customer records" \
  --event-id urn:uuid:22222222-2222-4222-8222-222222222222 \
  --occurred-at 2026-09-16T16:00:00Z \
  --key keys/normalize.private.pem \
  --out attestations/02-normalize.dsse.json

# 3. Separate the receiver: check its own policy before trusting it.
makoto policy check --policy receiver/policy.json

# 4. Sign the handoff over the exact graph and final artifact.
makoto handoff create \
  --head attestations/03-public-safe.dsse.json \
  --attestations attestations \
  --artifact-binding bindings/final-artifact.json \
  --schema-catalog receiver/catalog.json \
  --key keys/handoff.private.pem \
  --out bundle

# 5. Verify as the receiver, with receiver-held expectations.
makoto verify bundle bundle \
  --policy receiver/policy.json \
  --schema-catalog receiver/catalog.json \
  --expected-manifest sha256:<published manifest digest> \
  --expected-head sha256:<published head digest> \
  --expected-artifact receiver/expected-artifact.json \
  --json > report.json

Run the whole path, including private profiles and seven denial cases, with the end-to-end proof. Put step 5 in CI with any casebook gate workflow, then summarize the report when a downstream party needs a signed result.

What to ask for

Every row maps to the threat model, which follows the core failure-mode coverage matrix.

What Makoto does not cover

Makoto cannot establish that:

• a signer told the truth;
• a described transformation actually executed, unless a separately trusted Transform-track assessment establishes the execution controls, and even then it cannot establish that the transformation was correct;
• the source itself was correct, complete, licensed, safe, or legally usable;
• a bundle history is complete without an authorized handoff manifest, or fresh without an independently obtained expected manifest, head, or artifact set, nonce challenge, or consumer age policy; explicit replay acceptance waives rather than establishes freshness;
• an unavailable historical artifact still matches its recorded digest;
• a timestamp came from a trusted clock;
• a URI still serves the original bytes;
• signing keys were stored securely; or
• data is confidential merely because provenance exists.

Like SLSA, Makoto does not cover every way a producer can cause harm. It does not establish data-content correctness, code or model quality, freedom from bias or poison, the good intent of an authorized producer, confidentiality, legal compliance, deletion from every downstream copy, or the safety of a consumer that ignores a denial. A hardened platform limits who can tamper with an execution; it does not make the requested execution wise.

Handing off to a correctness process

Makoto will never certify data-content correctness. Its evidence is still what a correctness process needs. A downstream evaluator can consume Makoto's exact origin, operation, signer, graph, profile, and artifact identities; run domain tests, human review, calibration checks, retrieval evaluation, or model evaluation; and bind that result to the same digests in a separate attestation.

Makoto then supplies the stack trace for data needed to locate and replace a bad input or step. The downstream process owns the correctness judgment. That division keeps Makoto simple and transparent while making incorrect outcomes diagnosable and replaceable.