Glossary

A reference for Temporal-specific terms used throughout this wiki and the codebase. Where a term has a public-docs definition, the wiki page links to it; where it is purely internal (e.g. CHASM, HSM, RangeID) the canonical definition lives here.

Workflow concepts

• Workflow Execution — one durable run of a workflow definition, identified by (NamespaceID, WorkflowID, RunID). State is owned by the History service.
• Workflow ID — user-supplied logical identifier; survives resets and continue-as-new.
• RunID — UUID for one specific run; changes on reset or continue-as-new.
• Activity — a unit of side-effecting work scheduled by a workflow. Code runs in a user worker; the server only orchestrates.
• Workflow Task — a server-issued instruction to a worker to execute one slice of workflow code (until it blocks). Carries the new history events and returns Commands.
• Activity Task — a server-issued instruction to execute one activity attempt.
• Command — what a worker tells the server to do after a Workflow Task completes (ScheduleActivityTask, StartTimer, CompleteWorkflowExecution, …). Defined in temporal.api.enums.v1.CommandType.
• History Event — an immutable record appended to a workflow's history; the canonical event-sourcing log. Defined in temporal.api.enums.v1.EventType.
• Mutable State — the in-memory + persisted summary of a workflow execution that History uses to decide the next event to write. Implementation: MutableStateImpl.
• Continue-as-new — terminate a workflow run and start a new one with the same Workflow ID and a fresh history; used to bound history size.
• Reset — fork a workflow back to an earlier event. Produces a new RunID and a branched history tree.
• Speculative Workflow Task — a workflow task that does not yet appear in history. Used to deliver a Query or Update without bloating history when the task fails. See docs/architecture/speculative-workflow-task.md.

Server building blocks

• Shard / History Shard — a fixed slice of the keyspace hash(NamespaceID, WorkflowID) → ShardID. Owned by exactly one History host at a time; the unit of horizontal scaling.
• RangeID — monotonically increasing fence number for a shard. Each ownership change bumps it; stale writes are rejected.
• Task Queue — user-facing FIFO of pending Workflow / Activity tasks. Owned by the Matching service. Distinct from the per-shard "history task queues" in History.
• Task Queue Partition — Matching shards a single Task Queue across N partitions for throughput. The root partition forms a tree; childless partitions can forward to parents when a poller is idle.
• History Task — generic name for an item in one of History's internal queues (Transfer, Timer, Visibility, Archival, Replication, Outbound).
• Transfer Task — a History task that calls Matching to enqueue a Workflow or Activity task; used to implement the transactional-outbox pattern.
• Timer Task — a History task that fires at a wall-clock deadline (workflow sleeps, schedule-to-start timeouts, retry backoffs).
• Visibility Task — a History task that updates the visibility store (Elasticsearch / SQL) when workflow status changes.
• Outbound Task — a History task that drives a Nexus operation or callback to an external service.

Frameworks

• CHASM (Coordinated Heterogeneous Application State Machines) — the generalised state-machine framework in chasm/. Workflows, Schedulers, NexusOperations are all CHASM Libraries. Defined in docs/architecture/chasm.md.
• HSM (Hierarchical State Machine) — the in-shard state-machine library that powers callbacks and Nexus operations. Lives at service/history/hsm/.
• ASM (Application State Machine) — a registered CHASM Library — e.g. workflow, scheduler, nexusoperation.
• Component — a CHASM type; one node in an Execution's tree of components.
• VersionedTransition — CHASM's logical clock: (FailoverVersion, TransitionCount). Stamps every state change.

Networking & deployment

• Frontend — public-facing service; routes to History / Matching / Worker.
• Internal Frontend — optional second frontend for in-cluster traffic only (no auth surface).
• Ringpop — gossip-based membership library used to elect shard / task-queue owners. See common/membership/.
• XDC / Multi-cluster — cross-data-centre replication of namespaces and history events. Implementation in service/history/replication/ and service/worker/replicator/.

Persistence

• Persistence layer — pluggable storage abstraction, see common/persistence/. Implementations: Cassandra (cassandra/), SQL (sql/sqlplugin/{mysql,postgresql,sqlite}), and a fault-injection wrapper.
• Visibility store — separate index for queryable workflow metadata. Implementations under common/persistence/visibility/ (SQL) and Elasticsearch via the standard visibility manager.
• Search Attribute — a typed, indexed key/value attached to a workflow execution; queryable via the visibility store. See common/searchattribute/.
• Memo — unindexed key/value attached to a workflow execution.

Configuration

• Static config — YAML loaded at startup via common/config/. Things that cannot change without a restart (listen ports, persistence wiring).
• Dynamic config — runtime-tunable settings via common/dynamicconfig/. Cluster operators flip these without restarts.
• Namespace — administrative isolation boundary. Each namespace has its own retention, archival, and routing settings. See common/namespace/.

Other

• Nexus — Temporal's framework for composing services across namespaces / clusters. Source: common/nexus/, components/nexusoperations/, chasm/lib/nexusoperation/.
• DLQ (Dead-Letter Queue) — replication or task-execution failures that cannot be retried automatically end up here for manual inspection. Operator interface lives in tools/tdbg/ and the worker in service/worker/dlq/.
• TDBG — the operator CLI under cmd/tools/tdbg/. Lets engineers inspect / repair shards, replication tasks, DLQ contents.
• Fairness — the Matching priority/fairness scheduling system. Design notes in service/matching/fairness.md.