Token Semantics (BPMN)

The execution semantics of a BPMN process model are defined by tokens — abstract markers that represent the progress of a process instance. Tokens are not visible at runtime; they are a semantic device for reasoning about model behaviour.

Core mechanics

From sources/2018-dumas-fundamentals-of-bpm §3.1 and §3.2:

A token is created at a start event when a new process instance begins.
The token flows through the model along sequence flows.
The token is destroyed at an end event.
Activities consume an incoming token, perform their work, and produce an outgoing token.
Multiple instances of the same process model run independently — each has its own set of tokens (often visualised by colour).

The state (or marking) of a process instance at any point is the distribution of its tokens across the model's elements. This is exactly the Petri-net marking concept, mapped onto BPMN.

Gateway token semantics

Gateway	Split (1 in, N out)	Join (N in, 1 out)
XOR ◇X	Routes the incoming token to exactly one outgoing branch (based on conditions)	Pass-through: every arriving token is forwarded immediately to output
AND ◇+	Generates N tokens — one for each outgoing branch	Synchronises: waits for one token on each input, then merges them into a single output token
OR ◇O	Generates k tokens (1 ≤ k ≤ N), one for each branch whose condition is true	Synchronising merge: waits for all active branches to complete, then merges their tokens into one
Event-based ◇⬠	(Implicit) — the first event to arrive selects which branch fires	(rare)

The OR-join's "active branch" semantics is the most subtle: it waits for tokens only on incoming branches that will eventually deliver one. This requires global reasoning (sources/2018-dumas-fundamentals-of-bpm §3.2.3) and is the reason concepts/7pmg G5 cautions against OR usage.

Implicit termination

BPMN uses implicit termination semantics:

A process instance completes only when each token flowing in the model reaches an end event.

Consequences:

A model with multiple end events can have a single instance reach one end event with one token while another token is still flowing — the instance does not complete until all its tokens reach an end event.
This is why concepts/soundness clause (2) in Dumas's formulation says "each token must be in a different end event" at completion (multi-end variant).

A terminate end event (⊗) overrides this — firing one terminate end event force-completes the entire instance, discarding any other tokens. Use sparingly: it can hide modelling errors that would otherwise manifest as anomalies.

Multiple start events

BPMN also allows multiple start events, each capturing a different trigger. An instance is initiated by whichever start event fires first; only one start event creates the instance's initial token.

This is distinct from process variants — a single process can have multiple legitimate triggers (e.g., new purchase order or revised purchase order).

Why token semantics matter for the modeller

Three practical implications:

Anomaly reasoning: concepts/deadlock, concepts/livelock, concepts/lack-of-synchronization, concepts/dead-activity are all defined in terms of token movement. Reasoning at the token level is the right mental model when debugging unsoundness.
Gateway selection: choosing XOR vs AND vs OR is choosing token-multiplication semantics. "Do I want one token routed, or N tokens spawned, or k≤N tokens spawned?"
Parallel-branch correctness: AND-split + AND-join must be balanced — every token created at the split must arrive at the join. Bypass paths break this and cause concepts/deadlock or concepts/lack-of-synchronization.

Token-flow visualisation tools

bpmn-js-token-simulation (open-source, Camunda) — animate tokens through a BPMN diagram.
Camunda Cockpit — at runtime, visualises which task currently holds an instance's token.
ProM token-replay plug-ins — replay event-log traces over a model, surfacing where tokens fail to flow as expected (concepts/conformance-checking).

Mapping to Petri-net theory

BPMN's token semantics is essentially Petri-net token-flow (concepts/workflow-net) with notational sugar:

BPMN	Petri net
Activity	Transition
Sequence flow	Place + arc structure
Token	Token
AND-split	Transition with multiple output places
AND-join	Transition with multiple input places
XOR-split	Multiple transitions sharing an input place (free-choice)
End event	Sink place o

This mapping is what makes BPMN models mechanically verifiable for soundness via standard Petri-net tools — see sources/1998-vanderaalst-verification-of-workflow-nets §3.

concepts/workflow-net · concepts/soundness · concepts/deadlock · concepts/livelock · concepts/lack-of-synchronization · concepts/dead-activity · concepts/conformance-checking · concepts/7pmg · frameworks/bpmn

Sources

sources/2018-dumas-fundamentals-of-bpm §3.1, §3.2 · sources/1998-vanderaalst-verification-of-workflow-nets (formal foundation)