A signature is one check, not the verdict.
A receiver should be able to verify the evidence without access to the producer’s platform: parse the resources, authenticate each signed claim, decide whether each signer was authorized, reconstruct the source-to-handoff graph, resolve exact schemas, and hash the bytes that actually arrived.
What a real verdict checks
| Check | Question answered | What failure means |
|---|---|---|
| Structure | Do the statements, envelopes, profiles, policy, and handoff match their JSON Schemas? | The evidence is malformed or violates a required profile. |
| Cryptography | Do the DSSE signatures authenticate the exact payload bytes? | The metadata changed, the signature is invalid, or the key does not match. |
| Authorization | Does receiver-owned policy trust each key for this source, operation, profile, and handoff? | A mathematically valid signature was made by the wrong party. |
| Graph | Does every transformation point to the exact predecessor statement and input artifact? | A step is missing, rewired, duplicated, or disconnected from an origin. |
| Handoff | Does the signed manifest commit to the exact roots, heads, profiles, statements, and final artifacts? | The presented graph may be continuous but incomplete. |
| Freshness | Does an independent expected manifest, head, nonce, artifact, or age bound match? | An older valid handoff may have been replayed. |
| Data bytes | Do the bytes received by the consumer match the signed artifact digest? | The data changed after the claim was made. |
Run the reference verifier
Start with the deterministic handoff fixture. It produces one allowed bundle and seven denial cases, so the first experience includes the failure boundary as well as the happy path.
git clone https://github.com/makoto-project/makoto.git
cd makoto
uv sync --locked --dev
./scripts/demo-v0.2.sh --acceptanceTo inspect the receiver command directly:
uv run makoto verify bundle demos/v0.2-end-to-end/generated/positive-bundle \
--policy demos/v0.2-end-to-end/generated/receiver/policy.json \
--schema-catalog demos/v0.2-end-to-end/generated/receiver/catalog.json \
--expected-artifact demos/v0.2-end-to-end/generated/receiver/expected-artifact.json \
--evaluation-time 2026-09-16T16:00:00Z \
--jsonThe report keeps schema, signature, authorization, profile, graph, completeness, freshness, and artifact checks separate. A single boolean would hide which trust boundary failed.
Use hosted schemas for structural validation
The hosted schemas are ordinary Draft 2020-12 JSON Schemas. Any conforming validator can check an individual resource. This is useful at editors, CI gates, and ingestion boundaries, but it does not validate signatures, signer authorization, graph completeness, freshness, or data bytes.
uvx --from check-jsonschema check-jsonschema \
--schemafile https://usemakoto.dev/schema/v0.2/trust-policy.schema.json \
policy.jsonThe hosted catalog publishes every core schema and its SHA-256 digest. Private organizational profiles can use their own URI and remain unpublished; the signed profile reference pins the exact root and closure digests so a receiver can resolve them from an authenticated local catalog.
Content rules remain separate from integrity
A digest can prove that invisible Unicode or another dangerous string has not changed. It cannot make that string safe. Put normalization, control-character, field, or bounded-pattern rules in an organizational profile and require the receiver to validate the actual structured artifact against that profile.
What verification still cannot prove
Passing every check proves that exact bytes match authorized signed claims and the receiver’s independent expectations. It does not prove that a source told the truth, that a claimed transformation actually ran, that the data is safe or high quality, or that signed metadata is confidential. Those are separate controls and evidence.
Match the report contract, not just the JSON shape.
A useful implementation must preserve the distinctions between authenticity and authorization, continuity and completeness, and completeness and freshness. Start from the public schemas, conformance fixtures, denial reports, and reference implementation.