Workflow anatomy

Every workflow in the catalog has the same shape. Five sections, in order, each declarative. The harness reads them at boot, validates the schema, and refuses to start if anything is missing.

meta:
  slug: refund-request-intake
  category: billing
  version: 1.4.0
  authored: 2026-10-01

Identity. The slug is the catalog handle and the URL fragment. Version follows semver and bumps when intents or flow change. Authored is the first-published date — drift surfaces later in the run log.

intents:
  - id: refund_request
    confidence_floor: 0.7
  - id: invoice_question
    confidence_floor: 0.6

What the workflow recognizes. Each intent declares a confidence floor — below it, the harness asks one targeted clarification rather than guessing.

flow:
  - step: intake
    on: refund_request
    next: collect
  - step: collect
    fields: [invoice_id, reason, amount]
    next: confirm
  - step: confirm
    next: handoff

The conversation graph. Steps are stepwise, deterministic, and named — exactly the names that appear on the rail in the Live Preview. The harness rejects transitions outside the graph.

escalation:
  triggers: [low_confidence, customer_request, abusive_language]
  packet: [summary, intent, attempted_steps, fields_collected]

When and how to hand off to a human. Triggers are checked at every step; the packet is what the receiving human reads.

instruments:
  record:
    - intent_classification
    - confidence_per_turn
    - step_transitions
    - escalation_reason

What the harness records for every run. Recorded events are queryable in the run log and exportable as JSONL.