Platform Overview

Coding is writing at the level where the computer thinks. mashin is writing at the level where you think.

mashin is an intent-driven computing platform. You describe what you want in mashinTalk, a declarative language that reads like a plan. The platform handles execution, governance, recording, and deployment.

mashinTalk isn’t natural language, but it’s close: a small, structured vocabulary that maps to how humans describe what intelligent systems should do. The platform encodes the rest. This page unpacks what the platform is, what each component does, and how they connect.

Operational leverage

The intent layer absorbs the problems that consume most AI development effort today. Each of these is handled by the runtime, not application code:

Concern	Traditional	mashin
Authorization	Permission middleware in every service	Declared in `ensures`, enforced by kore
Audit trail	Custom logging + log aggregation	Behavioral ledger, automatic
Retry/recovery	Per-service retry logic	`retry` step, declarative
Deployment	Dockerfile, CI/CD, orchestration	`mashin launch`, one command
Observability	Tracing libraries, dashboards	Intent stream, built in
Governance	Policy engine + enforcement layer	Structural, cannot be bypassed

The result: developers write 30 lines of intent instead of 2,000 lines of plumbing. The 95% that was infrastructure becomes a property of the runtime.

Deployment is part of the abstraction

Traditional autonomous systems require separate deployment infrastructure: Dockerfiles, CI/CD pipelines, orchestration configs, health checks. In mashin, deployment is one command:

mashin launch                 # deploy to your Kortex (cloud)
mashin launch --cell home     # deploy to your Mac Mini
mashin launch --cell local    # run on this device

Same machine. Same governance. Same behavioral ledger. The deployment target changes. The guarantees do not.

The big picture

You write machines in mashinTalk, a purpose-built language designed to express intents naturally as structured thought. Machines run inside cells, your personal computing environments. Every execution is governed by kore, the formally verified governance kernel that mediates every intent, and recorded in a tamper-evident behavioral ledger. You publish machines as krates to kura, the package registry. Cells communicate through kortex, the governed network fabric. You build all of this in koda, the intelligent development environment, which renders its interface through kodex. End users interact with machines through kanvas, the graphical interface layer. Kanon, the governance ledger, records the provenance of every machine version.

Here is how the pieces relate:

You ──→ koda (IDE) ──→ write mashinTalk ──→ compile
                                                   │
                                                   ▼
                                            Cell (runtime)
                                            ├─ kore (governance kernel)
                                            ├─ Behavioral Ledger (execution trace)
                                            ├─ kanon (governance ledger)
                                            └─ kortex (network fabric) ──→ other cells

Published machines ──→ kura (registry) ──→ pulled into cells
Machines with UI ──→ kanvas (interface layer) ──→ end users

Why intent-driven computing matters

Traditional computing assumes programs directly execute effects. When requests.post(url) runs in Python, the HTTP request fires immediately. The program is the effect. Governing that program means inspecting it from the outside: wrapping it in middleware, scanning logs after the fact, bolting on policy layers that can be bypassed.

Intent-driven computing separates computation from effect. Programs produce intents: finite, structured data representing proposed actions. A governed runtime examines each intent, applies policy, records the decision, and only then realizes the effect. This separation is not a wrapper or middleware. It is a different execution model.

Traditional Computing	Intent-Driven Computing
computation executes effects	computation proposes intents
effects happen immediately	effects are mediated
governance is external	governance is structural
logs are observational	intent streams are complete
audit is reconstructive	audit is native
policies inspect behavior after execution	policies authorize behavior before execution
implementation-centric	intent-centric
syntax-centric	semantic-centric
English-dominant	language-localizable
code for machines	code understandable by humans

What this makes possible

These are emergent properties of operating at the intent layer, not features added to a system:

Structural governance. Rice’s theorem tells us that deciding arbitrary properties of arbitrary programs is, in general, impossible. But intents are not arbitrary programs. They are finite data structures. Governance decisions over intents are decidable. Governance becomes tractable as a structural property rather than an external operational concern.
Native auditability. Every intent produces a decision record: what was proposed, what policy was applied, whether it was approved or denied, and why. Audit is not reconstructed from logs after the fact. It is produced as a byproduct of execution.
Replayability. Because the runtime captures complete intent streams, you can replay any execution. This enables retrospective analysis, debugging, and regression testing against real production behavior.
Human comprehensibility. Intents are semantic. They describe what a program wants to do, not how it does it. A compliance officer can read an intent stream and understand what happened without reading source code.
Verification. Every intent decision is chained into a tamper-evident hash chain. The integrity of an execution trace is independently verifiable.
Policy simulation. You can replay historical intent streams against new policies before deploying them. “What would have happened if we had enforced this budget limit last month?” becomes a query you can run, not a question you have to guess at.

The abstraction shift

Major computing transitions happen when the abstraction level changes:

Era	Abstraction Shift
Assembly to C	machine operations to structured procedures
Servers to cloud	infrastructure to API calls
Imperative UI to React	DOM mutation to state intent
Procedural DB to SQL	storage traversal to data intent
Manual deploy to Kubernetes	deployment mechanics to desired state
Effect execution to intent-driven computing	effects to governed operational intent

Each transition trades direct control for a higher abstraction that makes new properties possible. You cannot get declarative queries from imperative storage traversal; you need SQL. You cannot get structural governance from direct effect execution; you need intent mediation.

Machines

A machine is the fundamental unit. It is a governed unit of intelligence: a computation that thinks internally and acts externally through a controlled boundary. Every machine has typed inputs, typed outputs, governance rules, and an implementation made of steps. Each .mashin file defines one machine.

Machines do not execute effects directly. A machine’s steps produce intents (call this API, query this model, write this file), and the runtime mediates each one. This is what makes machines governable by construction rather than by convention.

Machines are not scripts, notebooks, or agents in the LangChain sense. They are structured programs with contracts. The runtime enforces those contracts. See Machine Anatomy for the full structure.

mashinTalk

mashinTalk is the surface syntax of the mashin language. It uses keyword-hierarchy syntax: structural keywords determine program structure through indentation. No braces, no do...end. The keyword vocabulary is the grammar.

mashinTalk is designed to express intents, not implementation details. When you write ask classify, you are declaring an intent to invoke a reasoning capability. When you write call @mashin/actions/http/get, you are declaring an intent to make an HTTP request. The runtime decides whether and how those intents are realized.

machine email_classifier

  accepts
    subject as text, is required
    body as text, is required

  responds with
    priority as text
    category as text

  implements
    ask classify, using: "anthropic:claude-sonnet-4-6"
      with task "Classify this email by priority and category"
      returns
        priority as text
        category as text

This reads like a description of what the program wants to do, not how it does it. That is by design. mashinTalk is readable by compliance officers, not just developers. It is deterministic (one parse tree per program) and multilingual (the keyword vocabulary can be swapped for other natural languages while keeping the grammar).

Cells

A cell is your mashin environment. It is where your machines live, run, and store their history. Four properties define a cell: it is owned (your machines, your data, your keys), persistent (survives restarts and moves), networked (connects to other cells, the registry, and the cloud), and equivalent (every cell is a full peer; any cell is an equally valid position from which to observe and manage the entire network).

The same cell concept works everywhere: your laptop, a Docker container, a Mac Mini, a cloud VM. The code does not change between environments. A machine that runs in your laptop cell runs identically in a cloud cell.

The hierarchy: a machine is a governed unit of intelligence. A cell is where machines live. The medium is cells networked together via kortex.

See Cells for the full guide.

koda

Koda is the live intelligent development environment. It is not an assistant or chatbot bolted onto an editor. The entire interface is intelligent. You work in projects, books, and sessions, and koda provides context-aware help throughout.

What makes koda different: intelligence is ambient, not invoked. koda’s cognitive operations are themselves mashin machines in the @system/koda/* namespace, so they are governed, auditable, and inspectable. This is the Smalltalk property: the development environment is built from the same primitive as the things it builds.

See koda for the full guide.

kodex

Kodex is the text-first rendering surface where builders work inside koda. It is a character-grid interface with cell types at multiple depth levels: prose (summary), detail (full data), and trace (execution internals). Named from “codex” (bound manuscript), kodex renders execution traces, machine state, and governance decisions as structured text.

Kodex and kanvas are complementary: builders work in kodex, end users interact through kanvas.

kore

Kore is the formally verified governance kernel. It is extracted from Rocq (Coq) proofs and bridged to the runtime. Every intent passes through kore before it becomes an effect. Every governance decision at runtime runs through proved code: 41 modules, 572 theorems, 0 admitted lemmas.

This is what makes mashin’s governance claims provable, not just aspirational. The four Laws of Governed Intelligence are backed by machine-checked theorems. The expressiveness boundary and the governance boundary are mathematically proven to be coterminous: you cannot write a machine that escapes governance because the capability does not exist.

krates

A krate is the distribution unit in mashin. Every machine is a krate from birth: a versioned, signed package with its source, compiled artifact, governance rules, tests, and metadata. You do not “turn a machine into a package.” It already is one.

Krate metadata lives in krate.toml alongside the .mashin file:

[krate]
name = "email-triage"
version = "1.2.0"
description = "Classify and route incoming emails"
license = "MIT"

[krate.author]
name = "Your Name"

Every published krate is immutable, signed with Ed25519, and verified through six cryptographic levels. Krates use semantic versioning. You reference krates by namespace and path: @mashin/actions/http/get (stdlib), @myorg/billing/charge (organization).

kura

Kura is the package registry where krates are published, discovered, and pulled. Every published krate goes through six levels of cryptographic verification: file integrity, artifact identity, publisher authenticity, envelope integrity, registry attestation, and lineage provenance.

Kura supports federation. Organizations can run their own kura instance for internal machines while pulling public dependencies from the main registry.

See Publishing & kura for the full guide.

kortex

Kortex is the governed network fabric connecting cells. When a machine in one cell calls a machine in another cell, the call goes through kortex with governance on both sides: your cell checks that you are allowed to make the call, the remote cell checks that you are authorized to invoke that machine. Remote calls are intents like any other; they pass through kore before crossing the network boundary.

Three tiers of networking:

Local: cells on the same machine, zero configuration
Organizational: cells within the same organization, deployment-backed
Cross-organization: cells across organizations, portable governance

The directive interpreter is the networking layer. There is no separate “API gateway” or “service mesh.” Governance and networking are the same thing.

kanvas

Kanvas is the graphical interface layer where machines become reachable to end users. It supports MCP, REST, WebSocket, and webhooks. In mashinTalk, the expresses section declares what interfaces a machine provides.

Kanvas handles conventional web rendering (HTML, CSS, React) for deployed machine surfaces. Think of it as the front door: builders work through kodex, end users walk through kanvas.

kanon

Kanon is the governance ledger. It is the append-only record of machine provenance: who created a machine, every version change, every promotion, every derivation. While the behavioral ledger records what happened during execution (the runtime intent stream), kanon records the lifecycle of machines themselves (evolution events).

Kanon and kura are separated by design: kura stores artifacts, kanon records their lineage. You can verify not just that a machine is authentic, but that its entire version history is traceable.

kits

Kits is the composable framework layer. It is a collection of approximately 60 .mashin krates for building intelligent systems. Kits is to mashin what Phoenix is to Elixir: the conventions, patterns, and reusable machinery that turn a language into a productive platform.

In the composition hierarchy: atomics (L0) are built-in step types, stdlib (L1) provides effect machines like HTTP and file access, kits (L2) provides higher-level patterns and compositions, and applications (L3) are what you build from all of these.

Kits machines live under the @mashin/kits/* namespace.

The two ledgers

mashin maintains two separate ledgers:

Behavioral Ledger: the execution flight recorder. Every machine run produces a complete intent stream: what intents were proposed, what governance decisions were made, what the LLM said, how much it cost, and a hash chain proving nothing was tampered with. This is not a log assembled after the fact. It is the native output of intent-mediated execution.

Evolution Ledger: governed Git for machines. Every version change, promotion, and derivation is recorded. This is how mashin delivers lifecycle auditability. Combined with the behavioral ledger, you can answer both “what did this machine do?” and “how did this machine get here?”

The governance model

Governance in mashin is structural, not bolted on. It is a consequence of intent-driven execution: because programs produce intents rather than effects, every action passes through a mediation point where policy can be applied. The governance boundary and the expressiveness boundary are coterminous (the same boundary). You cannot write a machine that bypasses governance because the capability to do so does not exist in the language.

This is enforced at three levels:

Language level: compute steps are pure by construction (no I/O capability). All effects are expressed as intents that go through governed steps.
Runtime level: every intent passes through the governance interpreter, which checks permissions, enforces budgets, and mediates effects.
Kernel level: the governance interpreter is backed by kore, the formally verified kernel.

The ensures section in a machine declares what it can and cannot do. These are not annotations or comments. The runtime reads them and enforces them. See Governance for the language-level guide.

Next steps

Quickstart - Build and run your first machine in 5 minutes
Key Concepts - The fundamental language concepts
Cells - Understanding the runtime environment
koda - The intelligent development environment