What is mashin?

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

The word “coding” comes from “encoding”: translating from one form to another. For sixty years, programming has been translation. You know what you want. You encode it into the machine’s language. Every bug, every security failure, every governance gap lives in that translation.

mashin is the first intent-driven computing platform. You describe what you want: the goals, the decisions, the steps. The platform handles everything underneath.

You write machines in mashinTalk, a declarative language that reads like a plan. mashinTalk isn’t natural language, but it’s close: a small, structured vocabulary designed so humans and AI can both read and write it. The platform handles the encoding.

The abstraction arc

Every era of computing raised the level at which people work:

Era	You write like	What it freed you from
Assembly	the hardware	Counting registers and memory addresses
C	the machine	Chip-specific instruction sets
SQL	the question	Specifying how to search and sort data
HTML	the document	Rendering pixels, font metrics, layout math
CSS	the appearance	Positioning, painting, responsive calculations
Web frameworks	the application	Socket management, HTTP parsing
AI frameworks	the API	Raw model endpoints, prompt formatting
mashin	the human intent	Orchestration, governance, audit, deployment

SQL is the clearest precedent. You describe what data you want. The database figures out how to get it. mashin does for intelligent systems what SQL did for data.

Build at the speed of thought

Most AI development effort goes to plumbing. An email triage system needs the same things in any stack: orchestration, error handling, permission checks, an audit trail, tests, deployment. In most stacks, each of those is separate code you write, wire up, and maintain alongside the intelligence.

In mashin, each one is either a declaration in the machine document or a property of the runtime. Here is the whole program:

machine email_triage

  accepts
    emails as list, is required

  responds with
    urgent_count as number
    drafts as list

  behaves
    ask classify, using: "standard"
      with task "Classify each email by priority.\n\nEmails: ${input.emails}"
      returns
        classifications as list

    compute urgency
      {urgent_count: classify.classifications.filter((c) => c.priority == "urgent").length}

    decide route
      when urgency.urgent_count > 0
        ask notify, from: "@mashin/actions/slack/post_message"
          channel: "#ops"
          text: "Urgent emails need review"
      otherwise
        {notified: false}

    ask draft_replies, using: "standard"
      with task "Draft replies for the non-urgent emails: ${classify.classifications}"
      returns
        drafts as list

    compute done
      {urgent_count: urgency.urgent_count, drafts: draft_replies.drafts}

  ensures
    permissions
      allowed to
        model
        network.http
      requires approval for
        network.http.post

  verifies
    test "urgent email triggers a notification"
      assuming classify {classifications: [{subject: "Server down", priority: "urgent"}, {subject: "Newsletter", priority: "low"}]}
      assuming notify {sent: true, status: 200}
      assuming draft_replies {drafts: ["Thanks, noted."]}
      given {emails: [{subject: "Server down"}, {subject: "Newsletter"}]}
      expect {urgent_count: 1, drafts: ["Thanks, noted."]}

Every concern from the list has a home you can point to. Orchestration is the behaves flow. Permission checks are the ensures block, including the approval gate on outbound posts. The audit trail and observability are the behavioral ledger, which every run produces without instrumentation. Tests are the verifies block, runnable without an API key. Error handling is runtime policy: an unhandled failure halts the run and the ledger shows where. Turning it on is mashin deploy. What you write is the intelligence and the rules it runs under; the same document is the test suite and the deployment unit.

Machines you can build today

Morning Brief – Reads your calendar, email, and reminders. Speaks a summary via Siri.

Email Triage – Classifies incoming mail, routes by priority, drafts replies, holds sensitive actions for approval.

Meeting Prep – Gathers context from docs, past meetings, and participants. Delivers a briefing before you walk in.

Audio Briefing – Pulls RSS feeds, summarizes with AI, converts to speech for your commute.

See the Introduction to mashin course for full walkthroughs.

From idea to production in three commands

mashin new morning-brief     # scaffold a machine
mashin run morning-brief     # execute locally, see the trace
mashin deploy morning-brief.mashin   # live on your Kortex, accessible everywhere

No Dockerfile. No CI/CD pipeline. No deployment configuration. Write your intent, test it locally, ship it. The runtime handles authorization, recording, scaling, and governance in every environment.

From the Koda IDE, it is even simpler: click “Launch” in the Krate Editor.

The core idea

In traditional computing, code directly causes action. requests.post(url) IS the HTTP request. It happens immediately. Nothing mediates it.

In mashin, code proposes intents. ask fetch, from: "@mashin/actions/http/post" produces an intent to POST. The governance interpreter decides whether to allow it, records the decision, and only then executes. This is intent-driven computing: computation no longer directly causes action.

A machine is a governed unit of intelligence. It has inputs, outputs, steps, and rules. When a machine runs, the runtime mediates every intent and records every decision.

machine email_classifier

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

  responds with
    priority as text
    category as text

  behaves
    ask classify, using: "standard"
      with task "Classify this email by priority and category.\n\nSubject: ${input.subject}\nBody: ${input.body}"
      returns
        priority as text
        category as text

  ensures
    permissions
      allowed to
        model
      not allowed to
        network.http

  verifies
    test "classifies an invoice email"
      assuming classify {priority: "normal", category: "billing"}
      given {subject: "Invoice attached", body: "Your invoice for June."}
      expect {priority: "normal", category: "billing"}

This machine:

• Takes an email subject and body as input
• Uses an LLM to classify it
• Is allowed to reason (call an LLM) but not allowed to send email
• Returns structured output (priority + category)
• Every execution is recorded in the behavioral ledger

What makes mashin different

Programs produce intents, not effects. When you write ask fetch, from: "@mashin/actions/http/post", the runtime receives an intent to make an HTTP request. It checks permissions, records the decision, and only then executes. Nothing happens without authorization. This is not a wrapper around existing code. It is a different execution model.

Governance is structural, not bolted on. The governance boundary is the same as the expressiveness boundary. You cannot write a machine that bypasses governance because the capability to do so does not exist in the language.

Everything is auditable. Every execution produces a behavioral ledger trace: what steps ran, what decisions were made, what the LLM said, how much it cost, and a hash chain proving nothing was tampered with.

Human-readable by design. mashinTalk reads like a plan, not implementation code. It isn’t natural language, but it uses a small vocabulary that maps to how humans describe what intelligent systems should do: ask, decide, compute, call, remember. A compliance officer can read the permissions. A product manager can follow the steps. An LLM can write it. The intent layer is where humans, AI, and machines share understanding.

Replayable and verifiable. Every execution produces a complete intent stream. You can replay any run, apply new policies retroactively, verify the hash chain, and prove what happened. This is not logging. This is an event-sourced execution record.

Why it matters

Intent-driven computing makes governance tractable. Traditional programs are opaque: 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.

This means:

• Every action is authorized before execution, not monitored after
• Audit trails are structural, not reconstructive
• Policies can be verified mathematically, not just tested empirically
• New policies can be applied retroactively to historical intent streams

Three levels of working with mashin

Say what you want. Tell Koda: “Build me something that triages my email by urgency.” Koda designs the machine, picks the right approach, generates the plan. Most users work here.

Read and refine the plan. The machine Koda generates is a readable file. Classify the emails. Draft responses for the urgent ones. Combine the results. Anyone can read it, review it, adjust it. This is what gets saved, deployed, and governed.

The platform handles everything else. Which AI model to call, where to run it, how to authenticate, how to recover from failures, how to record every decision. You never see this. It just works.

The first level produces the second. The second produces the third. You describe your intent; the platform encodes it into action.

The platform

mashin is more than a language. It is a complete platform for governed intelligence:

Component	What it does
mashinTalk	The language. Keyword-hierarchy syntax that reads like structured thought.
Computer	Your mashin environment. Runs on your laptop, a server, or the cloud. Same code everywhere.
koda	The intelligent development environment. The entire interface is intelligent.
kore	The formally verified governance kernel. 746 theorems, 0 admitted.
kura	The package registry. Publish and discover machines with 6-level verification.
kortex	The governed network fabric. Computers communicate through governed channels.
kanvas	The interface layer. Where machines become reachable to end users.
kanon	The governance ledger. Append-only record of machine provenance.

See the Platform Overview for how all the pieces fit together.

Next steps

• Quickstart - Build and run your first machine in 5 minutes
• Key Concepts - Understand machines, steps, governance, and computers
• Platform Overview - How all the platform components work together
• Introduction to mashin - Full course: 10 lessons, one narrative