Lesson 9: Interpretation Modes

Your email triage is live, tested, and learning. Your manager asks: “What exactly does this thing do? How much does it cost? Is it compliant with our data handling policy?”

You could explain it yourself. Or you could ask mashin to analyze the machine and answer those questions directly.

Six Ways to Analyze a Machine

Type any of these in Koda:

/explain email_triage

You see a structured description: what the machine does step by step, what inputs it needs, what it outputs, what external systems it touches, what models it uses.

No need to read the code. The explanation is generated from the machine’s structure.

/cost email_triage

You see:

Estimated cost per run: $0.0003
  classify: claude-haiku-4, ~200 tokens, $0.0003
  route: decide (no cost)
  notify/task: effect machine (no AI cost)

At 150 runs/day: $0.045/day, $1.35/month

The cost estimate walks through every step, identifies which ones call AI models, looks up current pricing, and projects daily and monthly costs.

/simulate email_triage

Runs the machine with mocked effects. The AI steps return synthetic responses from your test cases. The Teams and Planner calls are simulated. You see the full execution flow without actually sending messages or creating tasks.

/evaluate email_triage

Runs the machine against all its verifies test cases and reports:

4/4 tests passed
Accuracy: 100%
Average confidence: 0.85

/verify email_triage

Runs a governance compliance check:

[pass] Valid structure
[pass] Capabilities declared
[pass] Models on allowlist
[pass] Step count within limits
[pass] Governance sections present
[pass] Derivation trust verified

This is the same check that runs before any machine is promoted to production. You can run it yourself anytime.

/improve email_triage

Proposes improvements: better prompts, missing edge cases, cost optimizations. Returns a diff showing what would change, without changing anything.

Using Modes in Code

Analysis is not just slash commands. The analyzers are machines, so you can call them from your own machines. Here is a deploy gate that evaluates a machine’s quality and blocks a release that falls short:

machine pre_deploy_check

accepts
  machine_source as text, is required

responds with
  ready as boolean
  blockers as list

implements
  ask quality, from: "@system/koda/evaluate"
    machine_source: input.machine_source

  compute assess
    let syntax_blockers = quality.valid_syntax != true ? ["invalid syntax"] : []
    let score_blockers = quality.overall_score < 7 ? ["quality score below 7"] : []
    let blockers = [...syntax_blockers, ...score_blockers]
    {ready: blockers.length == 0, blockers: blockers}

verifies
  test "blocks a low-scoring machine"
    assuming quality {overall_score: 3, valid_syntax: true}
    given {machine_source: "machine bad\n  implements\n    compute x\n      {result: 1}"}
    expect {ready: false, blockers: ["quality score below 7"]}
  test "clears a solid machine"
    assuming quality {overall_score: 9, valid_syntax: true}
    given {machine_source: "machine ok\n  implements\n    compute x\n      {result: 1}"}
    expect {ready: true, blockers: []}

ask quality, from: "@system/koda/evaluate" calls the evaluate analyzer the same way you call any machine, passing the target machine’s source as input. The analyzer reads the machine’s structure and returns a quality report; the compute step turns that report into a go / no-go decision. Compose more analyzers the same way to gate on governance, cost, and coverage together.

Custom Modes

The six built-in modes cover common needs. For specialized analysis, write your own analyzer machine. It takes a machine’s form as input and returns its verdict:

machine compliance_auditor

accepts
  target_form as text, is required
  target_name as text
  standard as text, default: "internal"

responds with
  compliant as boolean
  findings as list

implements
  ask audit, using: "anthropic:claude-sonnet-4"
    with role "You are a compliance auditor for AI systems."
    with task "Check this machine against ${input.standard} compliance standards.\n\nMachine: ${input.target_form}"
    returns
      compliant as boolean
      findings as list

verifies
  test "reports a compliance verdict with findings"
    assuming audit {compliant: false, findings: ["logs PII to an external channel"]}
    given {target_form: "machine x", target_name: "x", standard: "EU AI Act"}
    expect {compliant: false, findings: ["logs PII to an external channel"]}

Call it like any other machine, passing the target machine’s form as input:

ask audit_result, from: compliance_auditor
  target_form: input.target_form
  standard: "EU AI Act"

Because an analyzer is just a machine, you can version it, test it, and share it like anything else you build. There is nothing special about the built-in analyzers except that they ship with the platform.

The Bigger Picture

Interpretation modes exist because machines are structured data, not opaque code. The system can walk through a machine’s steps, read its models, check its governance, estimate its costs. All without running it.

This is what it means to have a governed platform: you can understand, audit, and verify any machine at any time.

What Comes Next

You have built, deployed, tested, and analyzed an email triage system. The final lesson goes deeper: how machines can inspect and improve themselves. Metaprogramming: the machine as a value that can be transformed.

Next: Metaprogramming →