Reference — the vocabulary of Cadence + Go durable execution. Updated each lesson. All lessons use terms consistently with this page.
Core model
Durable execution
An execution model where ordinary application code keeps running correctly across process restarts, infrastructure failures, and arbitrary pauses. You write a plain function; the engine makes it durable. [docs]
Workflow
The durable coordinator function. Cadence calls it a fault-oblivious stateful workflow: its local variables, threads, and timers survive worker and service failures. It decides what happens and in what order — but does no side-effecting work itself. Must be deterministic. [docs]
Activity
A single unit of side-effecting work called by a workflow: an API call, a DB write, an LLM call, a file read. Activities are where all non-deterministic and external interaction lives. They can fail and be retried without affecting workflow state. [docs]
Determinism
The rule that workflow code must produce the same result every time it is replayed. This forbids direct external calls, time.Now(), randomness, and raw goroutines inside workflow code — all of that goes in activities or via Cadence's workflow APIs. Determinism is what makes replay-based recovery possible. [docs]
Event sourcing / Replay
How workflow state is recovered. Cadence records every step as an event history. To restore a workflow, it re-runs the workflow code against that history, reconstructing local state exactly. Because the code is deterministic, replay produces the identical state. [docs]
Runtime pieces
Worker
A process (your Go program) that hosts workflow and activity code and polls Cadence for work to run. Workers are stateless and disposable — kill one mid-run and another (or the same, restarted) resumes the workflow from history. [docs]
Cadence service
The server that stores workflow event histories, schedules work, and hands tasks to workers. Workflows survive even the service restarting. [repo]
Task list
A named queue that routes work from the Cadence service to the workers that can handle it. Workers poll a task list; the service dispatches workflow/activity tasks onto it.
Domain
A namespace for workflows. Workflow IDs are unique per domain: only one open workflow with a given ID can exist in a domain at a time.
Control & structure
Signal
An asynchronous, point-to-point message delivered into a specific running workflow instance (e.g. "human approved stage 3"). Processed in the order received. The workflow can block waiting for one, making it the natural fit for a human-review gate. [docs]
GetSignalChannel
Go workflow API: workflow.GetSignalChannel(ctx, "name") returns a channel for a named signal. Calling .Receive(ctx, &out) parks the workflow until a matching signal arrives. [docs]
SignalWorkflow
Client API to send a signal to a running workflow by its workflow ID and signal name: client.SignalWorkflow(ctx, workflowID, runID, "name", payload). [docs]
SignalWithStartWorkflow
Client API that starts a workflow if it isn't running and delivers a signal atomically. Prevents the lost-signal race when an external event may arrive before the workflow exists. [docs]
Human task
The standard Cadence pattern for human-in-the-loop: an activity creates the task (email/Slack/record), the workflow blocks on a signal, and the human's action sends the signal back. Maps directly onto ICM review boundaries. [docs]
Query
A synchronous, read-only request to inspect a running workflow's current state without changing it.
Durable timer
A sleep/await inside a workflow that can last seconds or months. The workflow is removed from memory while waiting and resurrected when the timer fires — no process needs to stay running. In Go: workflow.Sleep(ctx, duration), never time.Sleep. [docs]
Child workflow
A workflow started by another via workflow.ExecuteChildWorkflow. Has its own event history, timeouts, retry policy, and can run on a different task list — but its lifecycle is shaped by the parent. Used to partition large problems or build reusable orchestrations. [docs]
ChildWorkflowFuture
What ExecuteChildWorkflow returns immediately. Call .Get(ctx, &out) to block on the child's result, or start several and block later to run children in parallel. [docs]
ParentClosePolicy
Per-child setting for what happens to a still-running child when the parent closes: Terminate (default, kill it), RequestCancel (let it clean up), or Abandon (let it keep running). [docs]
Standalone workflow
A top-level workflow started with a client, fully independent of any parent's lifecycle. The right choice over a child workflow when the process shouldn't share the parent's fate. [docs]
Retry policy
Configurable exponential backoff (initial interval, coefficient, max interval, max attempts, non-retryable errors) applied to activities and, optionally, whole workflows.
Activity behavior
At-least-once
Cadence does not recover activity state, so on failure it re-runs the activity. An activity may therefore execute more than once. [docs]
Idempotency
The property that running an activity twice has the same effect as running it once. Required because of at-least-once execution. For research outputs: overwrite by a stable key rather than append.
The four activity timeouts. ScheduleToStart: queued → picked up. StartToClose: worker start → return. ScheduleToClose: end-to-end cap. Heartbeat: max gap between heartbeats. Either ScheduleToClose, or both ScheduleToStart and StartToClose, is required. [docs]
Heartbeat
A periodic "still alive" call from inside a long-running activity. Enables fast worker-death detection and progress checkpointing (the heartbeat can carry a payload the retry resumes from). [docs]
NonRetryableErrorReasons
Retry-policy list of error types that should fail fast instead of retrying (e.g. malformed request, auth error) — failures that would never succeed on retry.
Local activity
An activity executed in the same worker process as the workflow, skipping the task-list round trip. Lower latency but less debuggability and higher duplicate-execution risk. Use for short, idempotent, non-critical work only. [docs]
Running it in Go
Starter
Any process that begins a workflow run via client.StartWorkflow(ctx, opts, WorkflowFunc, args...). Separate from the worker; can be a CLI or HTTP handler. [docs]
workflow.Channel
Cadence's deterministic replacement for a native Go chan. Required inside workflow code because native channels schedule non-deterministically and break replay. [docs]
workflow.Selector
Cadence's deterministic replacement for Go's select. Waits on multiple sources (signal channels, timers, futures) inside workflow code; whichever is ready first wins. [docs]
Ian's context
ICM (Interpretable Context Methodology)
The model behind Ian's existing research-assistant-workflow: the folder structure is the orchestration. Stages are folders with CONTEXT.md contracts; work passes as plain-text files; humans review at each boundary; stateless between runs. The comparison baseline for judging Cadence.
The 7 stages
Ian's research pipeline: intent → coordination → execution → evaluation → revision → knowledge → follow-through. The workload we map onto Cadence workflows and activities.