Token

A token is the conceptual marker BPMN uses to explain how a process executes. You never see a token in a diagram (it is not a shape) but every BPMN execution semantic is defined in terms of tokens: "the token arrives at the activity", "the token splits into two at a parallel gateway", "the token is consumed by the end event".

A process instance starts with one token at a start event. The token traverses sequence flows, triggering activities as it arrives and passing through gateways that route it. Parallel gateways multiply tokens, exclusive gateways pick one outgoing flow, inclusive gateways fire every matching flow. An instance ends when every token it spawned is consumed, either by reaching an end event or by being explicitly terminated.

The token model is how BPMN makes execution unambiguous. "This activity fires after that one" is vague. "The token from that activity arrives at this one" is precise. When two diagrams produce different behaviour for the same input, the answer is almost always in how tokens are created, split, or joined. Most BPMN bugs (inclusive joins that hang, parallel joins waiting for non-existent tokens, loops that never terminate) are token-flow bugs.

• Tokens let two different people reason about the same diagram and reach the same conclusion about what it does.
• Tokens let engines execute diagrams consistently: "put a token here, follow these rules" is deterministic.
• Tokens let you debug. When a process hangs, the question "where are the tokens?" has a concrete answer.

LucidFlow’s cost dashboard is built on token semantics: the weighted expected cost per instance assumes one token per start event and propagates it through every possible path in the diagram, weighting by branch probabilities. The bottleneck heatmap colours nodes by expected token visits (a high-frequency path is where tokens spend most of their time) so optimising the diagram follows the tokens, not just the shapes.