publishes

Esta página aún no está disponible en tu idioma.

The publishes surface declares events that a machine emits during execution. Other machines can subscribe to these events to build event-driven workflows. Each published event has a name and an optional schema that defines its payload structure.

Overview

Event publishing is how machines communicate asynchronously. Instead of one machine directly calling another with ask ... from, a publishing machine declares the events it may emit, and subscribing machines declare which events they listen for. This decoupling means publishers do not need to know their subscribers, and new subscribers can be added without changing the publisher.

Events are delivered through the cell’s event bus. Within a cell, delivery is immediate. Across cells (via Kortex), delivery follows the networking fabric’s reliability guarantees.

Syntax

expresses
  publishes
    order.created
      schema
        order_id as text
        customer_id as text
        total as number
    order.shipped
      schema
        order_id as text
        tracking_number as text

A complete machine with a publishes surface:

machine order_processor

  accepts
    order_data as map, is required

  responds with
    order_id as text
    status as text

  ensures
    permissions
      allowed to
        reason, http

  implements
    ask validate, using: "anthropic:claude-haiku-4-5"
      with task "Validate this order data"
      returns
        valid as boolean
        order_id as text
      assuming
        valid: true
        order_id: "ORD-2847"

    compute result
      {order_id: steps.validate.order_id, status: "created"}

  expresses
    publishes
      order.created
        schema
          order_id as text
          customer_id as text
          total as number
      order.failed
        schema
          order_id as text
          reason as text

Configuration options

Config	Required	Default	Description
Event name	Yes	-	Dot-delimited event name (e.g., `order.created`)
`schema`	No	-	Typed payload fields the event carries

Event naming conventions

Use dot-delimited names that follow {entity}.{action} or {domain}.{entity}.{action}. Examples: order.created, billing.invoice.paid. Names are case-sensitive; use lowercase with dots as separators.

Schema definition

Each event can declare a schema specifying the fields and types in its payload, using the same syntax as accepts and responds with. When a schema is declared, the runtime validates the payload before emitting the event. If the payload does not match, the event is rejected and the error is recorded in the behavioral ledger.

Governance

Every event emission is governed:

The machine’s step that triggers the event completes
The event payload is validated against the declared schema
Governance permissions are checked (the machine must be allowed to emit events)
A SurfaceAccess event is recorded with :publishes surface in the behavioral ledger
The event is delivered to the cell’s event bus

Events cannot bypass governance. A machine that is not permitted to publish events (via ensures) cannot emit them, regardless of what its expresses section declares.

Example

Publishing multiple events from different outcomes:

machine payment_processor

  accepts
    payment_data as map, is required

  responds with
    status as text
    transaction_id as text

  expresses
    publishes
      payment.succeeded
        schema
          transaction_id as text
          amount as number
          currency as text
      payment.failed
        schema
          transaction_id as text
          error_code as text
          reason as text
      payment.refunded
        schema
          transaction_id as text
          refund_amount as number

Subscribing machines listen for these events using the subscribes surface.