Flow concepts
Runtime is in development. These guides explain design intent; they are not a released API or installation reference. Read the release policy →
Model work, not just boxes
Section titled “Model work, not just boxes”A flow describes how a unit of work enters a system, changes shape, crosses external boundaries, and produces an outcome. Its most important properties often live between steps: time budgets, ownership, cancellation, and failure behavior.
This vocabulary is conceptual. It does not define the public Runtime schema or component names.
Identify four responsibilities
Section titled “Identify four responsibilities”| Responsibility | Design question |
|---|---|
| Entry | What starts the work and owns the initial acknowledgement? |
| Transformation | Which data shape changes, and what validation is required? |
| Side effect | Which step changes state in another system? |
| Outcome | What result is promised to the caller or event source? |
A transformation can usually be tested without a network. A side effect requires a contract for retries and duplicates. Keeping them separate makes both easier to reason about.
Draw failure boundaries
Section titled “Draw failure boundaries”For each external call, consider failures before sending, during processing, and after the remote side commits. The last case may leave you uncertain about the result. A retry could duplicate the side effect.
Record where the flow can safely stop. Cancellation of local work does not prove cancellation of remote work.
Make a reviewable artifact
Section titled “Make a reviewable artifact”Before implementation, produce an input/output contract, a sequence of steps, a side-effect inventory, and expected results for failure scenarios. No flow-language feature or transaction guarantee is implied by this checklist.
Continue with transformations and testing.