launch

launch

Asynchronous fire-and-forget execution. A launch step starts another machine in a separate process and immediately continues to the next step without waiting for the result. The launched machine runs independently. Use this for notifications, background jobs, logging, and any operation where the current machine does not need the outcome.

When to use

Use launch when you need to:

• Send a notification without waiting for delivery confirmation
• Start a background processing job
• Trigger an asynchronous workflow
• Fan out work to multiple machines without collecting results

Use ask ... from or action ... call when you need the result of the called machine. Use run to dispatch to a named flow within the same machine (synchronous). Use for each with action when you need to iterate and collect results.

Syntax

launch <name>
  machine: "<machine_path>"
  <input_key>: <value>
  ...

Batch launch (launch_many)

launch_many <name>
  machine: "<machine_path>"
  items: <collection_expression>
  input_key: "<key_name>"
  extra_input: { <key>: <value>, ... }
  max_concurrency: <number>
  collect: true|false

Configuration

Single launch

Config	Required	Description
machine	Yes	The machine to launch. Path format: "@mashin/actions/notifications/send", "@myorg/workers/process".
Input keys	Varies	Key-value pairs passed as input to the launched machine.

Batch launch (launch_many)

Config	Required	Description
machine	Yes	Machine to launch for each item.
items	Yes	Collection expression. One machine instance is launched per item.
input_key	No	Key name for the current item in the launched machine’s input. Default: "item".
extra_input	No	Additional input merged into each launched instance.
max_concurrency	No	Maximum parallel launches. Default: 10.
collect	No	If true, wait for all results and return them. If false, return run IDs immediately. Default: false.

Examples

Send a notification

machine order_processor
  accepts
    order_id as text, is required
    customer_email as text, is required

  implements
    compute process_order
      {status: "complete", order_id: input.order_id}

    launch send_confirmation
      machine: "@mashin/actions/notifications/send"
      channel: "email"
      recipient: input.customer_email
      subject: "Order " + input.order_id + " confirmed"
      body: "Your order has been processed successfully."

    // This step runs immediately, does not wait for the email
    compute respond
      {order_id: input.order_id, status: "complete", notification_sent: true}

Event-driven launch

machine event_processor
  implements
    subscribes
      on "payment.failed" launch alert_team
      on "user.signed_up" launch send_welcome

    flows
      flow alert_team
        action notify call
          machine: "@myorg/alerts/slack"
          channel: "#payments"
          message: "Payment failed for " + event.customer_id

      flow send_welcome
        action send call
          machine: "@myorg/onboarding/welcome_email"
          user_id: event.user_id

Batch launch: process documents

machine batch_processor
  accepts
    documents as list, is required
    analysis_type as text, default: "summary"

  responds with
    successful as number
    failed as number
    results as list

  implements
    launch_many analyze_all
      machine: "document_analyzer"
      items: input.documents
      input_key: "document"
      extra_input: {analysis_type: input.analysis_type}
      max_concurrency: 10
      collect: true

    compute summarize
      {
        successful: analyze_all.results.filter(r => r.status == "ok").length,
        failed: analyze_all.results.filter(r => r.status != "ok").length,
        results: analyze_all.results
      }

Fire-and-forget batch (no collection)

// When you don't need results back
launch_many send_notifications
  machine: "send_email"
  items: get_subscribers.users
  input_key: "recipient"
  extra_input: {subject: input.subject, body: input.body}
  // No collect = fire-and-forget, returns immediately with run IDs

Governance

Every launch step is governed (Inv 3: Governance Mediation):

1. Permission check: the machine must have machine.call capability
2. Directive emission: the launch emits a directive mediated by the governance interpreter
3. Behavioral ledger: the launched machine path, input keys, and spawned run ID are recorded
4. Independent governance: the launched machine runs under its own governance rules in its own execution context

The key governance distinction from ask ... from: launch creates a new execution with its own run ID, ExecStart/ExecEnd events, and hash chain. The parent machine’s trace links to the child’s run ID but does not contain the child’s internal step events.

In test mode, launch steps are recorded but do not actually spawn a new machine process.

Translations

Language	Keyword
English	launch
Spanish	lanza
French	lance
German	startet
Japanese	起動
Chinese	启动
Korean	시작

See also

• ask … from - Synchronous machine call (waits for result)
• run - Execute a named flow within the same machine
• wait for - Suspend until an event arrives
• for each - Iterate over a collection with result collection
• implements - The section where launch steps live