Define a workflow

A small, complete definition

{
  "name": "hello-docs",
  "version": "1.0.0",
  "default_group": "python-standard",
  "phases": {
    "start": {
      "requires": [],
      "service": "hello",
      "scope": "root",
      "mode": "sync_lambda"
    },
    "finish": {
      "requires": [
        "start"
      ],
      "service": "hello",
      "scope": "fan_in_all",
      "terminal": true,
      "mode": "sync_lambda"
    }
  }
}

name: hello-docs
version: 1.0.0
default_group: python-standard
phases:
  start:
    requires: []
    service: hello
    scope: root
    mode: sync_lambda
  finish:
    requires:
      - start
    service: hello
    scope: fan_in_all
    terminal: true
    mode: sync_lambda

The important fields

Outcomes and rework

Handlers return completed or a declared named outcome. Route rework with rerun_phase and max_loops.

Rework exhaustion can advance the flow. Use an explicit review/failure path when publication must stay blocked.

Runtime groups & worker slices

Phases run in installed runtime groups. Worker memory sets handler slice limits, timeouts and proportional CPU (1,769 MiB = 1 vCPU; slices share container vCPUs without cgroup throttling).

Per-phase memory overrides are rejected; profile locally with rippflow test --profile. For workloads exceeding 3,072 MiB or requiring custom VPC/IAM, use synchronous Lambda (up to 10 GiB, 15m) or asynchronous jobs via callbacks.

Runtimes & resources guide → · Internal memory & slice contract (GitHub) ↗