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

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

Namespace	Who publishes	Example
@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:

Level	What it checks
File integrity	SHA-256 hash of every file in the krate
Artifact identity	The compiled artifact matches the source
Publisher authenticity	Ed25519 signature from the publisher’s computer identity
Envelope integrity	The package metadata was not tampered with
Registry attestation	kura verifies and co-signs the submission
Lineage provenance	The 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. Compile: mashin compile turns the machine into a frozen artifact
3. Test: mashin test runs the verifies suite
4. Publish: mashin publish signs and uploads to kura

mashin compile greeting.mashin && mashin test greeting.mashin && mashin publish greeting.mashin

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:

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

• Computers - Where published machines run
• Deployment - Getting to production
• Composition - Building machines from published machines