From source bytes to an independently verified handoff
This deterministic walkthrough starts with synthetic customer data, records an origin, applies normalization and public-safe transformations, signs the exact handoff, and lets a receiver verify schemas, signatures, authorization, graph completeness, and final bytes.
Evidence boundary. This page presents checked-in evidence; it does not perform verification. Trust these bytes only when the website pin identifies the exact core revision and the receiver command below returns allow.
The complete story
Manifest: b83a5cd1870b8ce1f2931650611f0a19deed0796c0f262e4632efc17981f695c · Head: 962be71738a0146642d27c87fba3c7338b0f2bb764b113b16867bb4808b11977 · Final artifact: 2f4fe11d8b533357fa0fdb890f1a714047393c962d75c8dd8cbb009e01fbd9f4
Clone and run
These are the repository's canonical acceptance commands.
git clone https://github.com/makoto-project/makoto.git
cd makoto
uv sync --locked --dev
./scripts/demo-v0.2.sh --acceptanceThe measured run creates all three provenance events plus the handoff, verifies the positive bundle, checks seven negative fixtures, and removes its ignored work directory. It requires no cloud credentials, service, or Docker.
Send the bundle; verify as the receiver
The sender transfers only the signed bundle. The receiver keeps its trust policy, schema catalog, and expected artifact outside that bundle, then runs the verifier against the received bytes.
MAKOTO_RECEIVER_DIR="$(mktemp -d)"
cp -R demos/v0.2-end-to-end/generated/positive-bundle "$MAKOTO_RECEIVER_DIR/bundle"
uv run makoto verify bundle "$MAKOTO_RECEIVER_DIR/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-manifest sha256:b83a5cd1870b8ce1f2931650611f0a19deed0796c0f262e4632efc17981f695c \
--expected-head sha256:962be71738a0146642d27c87fba3c7338b0f2bb764b113b16867bb4808b11977 \
--expected-artifact demos/v0.2-end-to-end/generated/receiver/expected-artifact.json \
--evaluation-time 2026-09-16T16:00:00Z \
--jsonThe expected result is "decision":"allow". Download and inspect the exact source data, normalized data, final public data, or the final bytes carried in the bundle. The receiver expectation is also downloadable.
Open the exact source revision. This exact commit link identifies the implementation snapshot used for these artifacts.
Inspect the evidence
Origin, normalize, and public-safe signed statements
Each DSSE envelope contains exact payload bytes and one Ed25519 signature. The statement digest hashes the decoded payload, so adding a valid co-signature does not change graph identity.
Private organizational profiles
The final statement references one predicate profile and one structured-artifact profile by URI, root digest, and closure digest. The receiver resolves both from an external catalog; the producer bundle does not carry or control the private schema bytes.
Consumer trust policy
The policy maps key IDs to public keys, selects allowed source/operation claims, sets signature thresholds, requires a freshness anchor, pins profile requirements, and carries resource ceilings.
Signed handoff manifest and bundle index
The handoff signs the exact statement, root, head, final-artifact, recipient, and profile-requirement sets. The unsigned bundle index only maps those logical identities to transport paths.
Positive verification report
Open the complete report. It records separate checks for schemas, cryptography, authorization, profiles, graph, completeness/freshness, and artifact bytes.
decision: allow
manifestDigest: b83a5cd1…
head: 962be717…
artifact: 2f4fe11d…Positive proof
- Core schemas, private profiles, all signatures and authorizationsPASS
- Origin roots, predecessors, input bindings, acyclic exact graphPASS
- Expected manifest, expected head, and final artifact bytesPASS
- Receiver decisionALLOW
Five attack stories, seven executable cases
1. Mutate final data after signing — E_ARTIFACT_DIGEST
A one-byte change leaves metadata and signatures intact but breaks the terminal artifact hash.
2. Edit signed metadata — E_SIGNATURE_INVALID / E_STATEMENT_DIGEST
Editing payload bytes without the signing key invalidates the signature. If the unsigned index still claims the earlier statement digest, indexing rejects that mismatch first.
3. Remove or rewire a step — E_PREDECESSOR_MISSING / E_SIGNATURE_INVALID
Deleting a predecessor breaks graph continuity. Rewriting the signed predecessor binding without re-signing breaks authenticity.
4. Violate a private data-content profile — E_PROFILE_INVALID
The attacker consistently regenerates and re-signs the final bytes, but the receiver's independently pinned schema rejects the reintroduced direct identifier.
5. Use a known but unauthorized signer — E_SIGNER_UNAUTHORIZED
The attacker's public key is configured, so the cryptographic signature can pass. It is absent from every matching authorization rule and therefore cannot authorize the statement.
Two distinctions the report keeps explicit
- Authenticity ≠ authorizationAuthenticity asks whether a signature is mathematically valid for a key. Authorization asks whether the receiver trusts that key for this source, operation, profile, and threshold at evaluation time.
- Continuity ≠ completenessContinuity proves every presented step links correctly to its predecessors. Completeness needs an authorized signed handoff that commits to the exact graph and final artifacts.
- Completeness ≠ freshnessAn older valid complete handoff can be replayed. Expected manifest, head, and artifact values, a nonce, or bounded age provide independent freshness.
Next integration step
Orchestrators, warehouses, stream processors, and data tools can emit or carry these envelopes. Makoto standardizes the evidence and verification boundary; it does not claim that conceptual adapters on this site are production packages. Review the integration contract and platform field notes.