Workflow Vocabulary
Vyuh Workflows has three core durable concepts: operations, work, and events. Timers and structured composition build larger flows from those three ideas.
The Three Core Concepts
| Concept | Meaning | Workflow verb | Counterparty verb |
|---|---|---|---|
Operation<I, O, E> | Automated, effectful execution performed by registered code | flow.perform(...) | an OperationHandler executes it |
Work<I, R> | Assigned work requested from an actor | flow.request(...) | the actor responds |
Event<P> | A typed fact sent from outside the current execution path | flow.waitForEvent(...) | a caller sendEvents |
An actor is anything that can accept and respond to work: a person, user, group, role, agent, bot, or service. The engine does not create a separate workflow primitive for each actor kind. Audience identifies who is eligible; assignee identifies who claimed a particular WorkItem.
Contracts and Implementations
| Noun | Meaning |
|---|---|
Schema<T> | Reusable, versioned data contract with typed encoding and validation. |
Workflow<I, O, E> | Versioned workflow contract for input, success, and expected failure. |
Operation<I, O, E> | Versioned automated-operation contract for input, success, and expected failure. |
Work<I, R> | Versioned assigned-work contract with request I and response R. |
Event<P> | Versioned external-event contract carrying payload P. |
Query<A, R> | Versioned read-only query contract. |
WorkflowHandler<I, O, E> | Deterministic executable produced by Workflow.implement. |
OperationHandler<I, O, E> | Effectful executable produced by Operation.implement. |
WorkflowExecution<E> | Deterministic scope passed to a workflow handler. |
OperationExecution<E> | Effectful scope passed to an operation handler. |
WorkItem | Durable runtime instance created by flow.request(...). |
Audience | Users, groups, roles, agents, or services eligible to respond. |
Durable Primitives
Workflow handlers compose the following primitives directly:
| Primitive | Purpose |
|---|---|
perform | Run an operation with retries, timeout, idempotency, and annotations. |
request | Create a WorkItem and wait for an actor's typed response. |
waitForEvent | Wait for a typed event; early events are buffered durably. |
sleep | Wait on a durable timer. |
workflow | Call a child workflow and wait for its result. |
spawn / join | Start a child independently and join it later. |
parallel | Fork named branches and merge after every branch completes. |
race | Fork named branches and accept the first durable result. |
quorum | Merge after the required number of branches complete. |
forEach | Run a stable-keyed durable fan-out, optionally in bounded batches. |
saga | Compensate completed operations in reverse order after failure. |
query | Expose a typed, read-only view of replay state. |
continueAsNew | Close a long history and atomically continue in a successor run. |
fail / cancel | End with an expected failure or cancellation. |
What Durable Means
Every blocking boundary has a stable operation ID. The runtime commits its command and history before execution continues. After a crash, restart, or move to another server, it replays the same workflow version, returns recorded results for resolved boundaries, and stops at the first unresolved boundary. The logical workflow therefore resumes exactly where it stopped without persisting a Dart stack or keeping a process alive.
Operation handlers may perform real I/O, so they must use the supplied stable idempotency key. Durability prevents lost orchestration progress; idempotency prevents a retried external effect from being applied twice.