Skip to content
mashin

Publishing & kura

Every machine in mashin is a krate from birth. A krate is a versioned, signed package that can be published to kura (the registry) and used by others. Publishing is a promotion step, not a separate concept: you build a machine, test it, and when it is ready, publish it for others to use.

What is a krate

A krate contains:

  • The machine definition (compiled .mashin artifact)
  • Metadata: name, version, description, author, license, tags
  • Governance rules (the ensures section, baked into the artifact)
  • Signatures (Ed25519, proving who published it)
  • Test suite (the verifies section)

Metadata lives in krate.toml, not in the .mashin file:

[krate]
name = "email-triage"
version = "1.2.0"
description = "Classify and route incoming emails by priority and category"
license = "MIT"
tags = ["email", "classification", "triage"]


[krate.author]
name = "Your Name"

Publishing to the registry

Terminal window
mashin publish

This builds, tests, signs, and pushes the krate to kura. If any test fails, the publish is blocked.

Versioning

Krates use semantic versioning. Bump the version in krate.toml before publishing:

version = "1.3.0"

Each published version is immutable. You cannot overwrite a published version. To fix a bug, publish a new version.

Using published machines

Reference published machines in your own machines with ask ... from:

ask classify, from: "@myorg/email/triage"
  subject: input.subject
  body: input.body
  returns
    priority as text
    category as text

Or declare dependencies in krate.toml:

[dependencies]
"@mashin/actions/http" = "^1.0"
"@myorg/email/triage" = "^1.2"

Namespaces

NamespaceWho publishesExample
@mashin/*Official standard library@mashin/actions/http/get
@orgname/*Your organization@myorg/billing/charge

Organization namespaces are claimed when you create an organization on mashin.live.

Verification levels

Every published krate goes through six levels of verification:

LevelWhat it checks
File integritySHA-256 hash of every file in the krate
Artifact identityThe compiled artifact matches the source
Publisher authenticityEd25519 signature from the publisher’s cell identity
Envelope integrityThe package metadata was not tampered with
Registry attestationkura verifies and co-signs the submission
Lineage provenanceThe evolution ledger traces the version history

This is not optional. Every krate published to kura passes all six levels. When you pull a machine from the registry, you know who published it, that it was not tampered with, and that its entire version history is traceable.

The publish flow

  1. Update krate.toml: bump version, update description if needed
  2. Build: mashin build compiles the machine
  3. Test: mashin test runs the verifies suite
  4. Publish: mashin publish signs and uploads to kura
Terminal window
mashin build && mashin test && mashin publish

If tests fail, the publish is rejected. If the version already exists, the publish is rejected. There are no overrides.

Discovery

Find machines published by others:

Terminal window
mashin search "email classification"
mashin info @myorg/email/triage

The registry shows each krate’s description, governance rules, test results, version history, and publisher identity. You can evaluate whether a machine meets your governance requirements before pulling it.

Private registries

Organizations can run their own kura instance for internal machines. The same verification levels apply. Private registries federate with the public registry, so you can mix public and private dependencies.

Try it

Package a machine you have built as a krate. Create a krate.toml with name, version, and description. Run mashin build && mashin test && mashin publish. Then reference the published machine from another machine using ask ... from.

Next steps