ii — Workflows

Workflows are defined as data, not code.

Every automation is a set of YAML definitions that compile into a typed graph before anything runs. Invalid definitions are rejected before they register, with errors naming the file, the field, and the rule violated. The engine itself never changes for your business, no matter how many automations you add.

audit.yamlrender.py

what you write

kind: trigger

version: 1

source: webhook

---

kind: task

version: 1

runner:

kind: agent

spec: audit.analyst@3

input: report.request@1

output: report.spec@1

uses:

policy:

timeout: 90s

retry: 2

idempotent: true

---

kind: task

version: 1

runner:

kind: script

runtime: python

entry: render.main

input: report.spec@1

pipelines/audit.yamlSpaces: 2UTF-8YAML

ptn applywhat gets built

report.request@1trigger · webhook

derived from on:

gather@1task · agent

derived from uses:

ledgerpostgres · query

receiptsobject store · get

fx_rateshttp · request

derived from then:

render@1task · script

declared output

report.htmlvalue · file

No edges are drawn by hand. Every arrow above comes from an on:, then:, or uses: reference — hover either side to see which.

four primitives

Trigger: cron · webhook · manual
Task: script · agent
Resource: postgres · object store · http
Approval: approvers · timeout

five values — everything passed between tasks

Text: plain text
File: a file, passed by handle
Table: rows and columns, passed by handle
Record: structured data, checked against a schema
Error: a typed failure

That is the entire vocabulary, and it is closed on purpose. Your business data lives in Records, checked against schemas you register, so the engine never needs custom code for your domain and adding more workflows never changes the engine.