Workflow Tokenisation | How Processes Become Steps, Actions, States and Decisions

A workflow is continuous human and machine activity represented as a sequence of steps, decisions, states and handoffs. Workflow tokenisation is the process of deciding which parts of that activity deserve discrete identities so systems can model, compare, automate and audit how work moves.

A purchase request, lesson plan, hospital admission, publishing pipeline or software deployment can all be represented as workflow tokens. The useful unit might be an action, state transition, approval, role handoff, exception or completed stage.

This article continues the eduKateSingapore Representation and Tokenisation series and builds on Event Tokenisation.

The Workflow Representation Route

REAL WORK
→ OBSERVED ACTIONS
→ EVENTS
→ STEP / STATE / ROLE TOKENS
→ ORDER + DEPENDENCIES
→ DECISIONS + BRANCHES
→ WORKFLOW MODEL
→ EXECUTION / ANALYSIS / AUTOMATION
→ RESULT
→ AUDIT + WORLD RETURN

1. A Workflow Is a Representation of Work

Real work contains conversations, waiting, interruptions, improvisation and tacit knowledge. A workflow model selects the parts important enough to record.

The model is useful precisely because it simplifies—and dangerous if it simplifies the wrong things.

2. Steps Are Coarse Event Tokens

“Review application” can compress dozens of clicks, checks and conversations into one stage.

Step granularity determines how much operational detail survives.

3. Actions Are Finer-Grained Tokens

Open file, verify identity, calculate total, approve request and send notification can each become one action token.

Fine action logs support diagnosis but create long sequences.

4. States Describe What Is True Between Actions

Draft, submitted, under_review, approved and rejected are states.

Workflow reasoning often alternates action → new state → next action.

5. State Transitions Create the Workflow Grammar

Not every state can legally follow every other state. Submitted may move to under_review, but perhaps not directly to archived.

Transition rules define allowed process structure.

6. Sequence Alone Is Not Enough

Two actions can happen in parallel, one can depend on several predecessors, and a workflow can branch.

Workflow representation often needs graph structure in addition to order.

7. Dependencies Are Relationship Tokens

“B can start only after A finishes” is different from “B usually follows A”.

Hard dependency and observed sequence should remain distinct.

8. Decisions Create Branches

A condition such as score ≥ 75 can route one case to pass and another to review.

The decision token needs both condition and outcome.

9. Decision Logic Should Be Explicit

If a workflow branches because of an unwritten human judgement, later automation can imitate the branch without understanding why.

Important decision criteria should be represented, not merely inferred from history.

10. Roles Are Part of Workflow Meaning

Teacher approves, student submits, administrator verifies and system sends can be distinct workflow permissions.

The same action performed by a different role can have different authority.

11. Role Tokens Should Not Become Person Tokens

A role such as reviewer can be filled by several people. The role identity should remain separate from the human identity performing it.

This protects both flexibility and provenance.

12. Handoffs Are Workflow Boundaries

When work moves from one team or system to another, context can be lost.

A handoff token should preserve what was transferred, by whom and under what state.

13. Waiting Is Part of the Process

A workflow can spend more time waiting than executing.

Ignoring queue and wait states creates a misleadingly efficient representation.

14. Duration Should Be Attached to Steps

Two workflows can contain identical step sequences while one takes five minutes and the other five days.

Time is an operational dimension of workflow tokens.

15. Start Time and Completion Time Are Different Evidence

A task can begin, pause and resume before completion.

One timestamp cannot represent the full activity lifecycle.

16. Workflow Events Need Stable Case Identity

In process mining, events are usually grouped into cases such as one order, application or patient journey.

Without case identity, events from different processes can be mixed into a false sequence.

17. XES Standardises Event-Log Interchange

The active IEEE 1849-2023 eXtensible Event Stream (XES) standard defines an interoperable format for event logs and event streams used in process analysis.

The standard’s importance here is representational: event syntax and event semantics must be clear enough to move between systems without losing what the log means.

18. Event Logs Are Observations of Workflow

An event log records what systems observed—not necessarily every action that actually occurred.

Process mining can only reconstruct behaviour that the event representation captured.

19. Missing Events Create Phantom Shortcuts

If an approval step is performed manually and never logged, the data may show submitted → paid even though approval occurred in between.

Observed sequence is not always full process sequence.

20. Duplicate Events Create Phantom Rework

Retries or integration errors can log one activity twice.

Deduplication rules need stable event identity and source provenance.

21. Process Models Can Be Designed or Discovered

A designed workflow says how work should happen. Process mining discovers patterns in event logs showing how work did happen.

Normative and observed representations should remain separate.

22. Conformance Checking Compares the Two

A case can be compared with the approved workflow to find missing, skipped or reordered steps.

This makes workflow representation auditable rather than merely descriptive.

23. Exceptions Are Part of the Real Workflow

Returns, escalations, emergency overrides and failed payments are not noise. They are often where the system’s resilience is tested.

Exception tokens deserve first-class representation.

24. Happy-Path Models Can Hide Operational Risk

A diagram showing only the common route can look elegant while omitting the conditions that make production systems difficult.

Workflow fidelity requires negative paths too.

25. Retries Are Different From Repeats

Repeating an educational exercise can be intended practice. Retrying a failed API call can be fault recovery.

The same visible action sequence can have different workflow semantics.

26. Loops Need Explicit Representation

A workflow can revisit one stage until a condition is met.

Flattening a loop into a fixed list loses the control rule.

27. Parallelism Needs More Than One Linear Order

Two reviews can occur concurrently. Serialising them arbitrarily as A then B can imply a dependency that does not exist.

Partial ordering is often more faithful than one timeline.

28. Synchronisation Creates Join Conditions

A later stage may wait until two parallel branches both complete.

The workflow needs an AND-join relation rather than a simple next token.

29. Optional Steps Need Conditions

A medical referral, secondary review or refund step may apply only to selected cases.

Optionality should be represented as conditional structure, not missing data.

30. Deadlines Are Workflow Constraints

A task may be correct but late.

Time limits, service-level targets and expiry conditions belong to the process representation.

31. Escalation Is a State + Authority Change

When a case escalates, it often changes priority, role ownership and permissible actions.

Escalation should not be represented as merely another message.

32. Workflow Granularity Should Match the Question

An executive may need five stages. An operator may need fifty actions. An auditor may need every event.

The same process can have several valid token scales.

33. Hierarchical Workflows Preserve Several Scales

A high-level “publish article” stage can contain commission → research → edit → approve → publish → verify.

Hierarchy allows strategic overview and operational detail to coexist.

34. Workflow Tokens Can Feed Sequence Models

Activity IDs, state IDs and time-gap tokens can become model inputs for next-step prediction, delay prediction or anomaly detection.

The vocabulary contains process actions instead of words.

35. Next-Step Prediction Is Not Workflow Authority

A model can predict that users usually skip an approval stage. That does not mean skipping is permitted.

Observed frequency and authorised process remain separate.

36. AI Agents Need Typed Workflow States

An agent deciding what to do next needs to know whether a task is awaiting evidence, awaiting approval, executable or complete.

Explicit state is safer than inferring authority from conversational prose.

37. Tool Calls Are Workflow Actions

Search, database query, email draft and publication are distinct action types with different side effects.

Workflow representation should distinguish read operations from writes.

38. Approval Tokens Need Scope

“Approved” must identify what was approved: one article, one batch, a budget or a release.

Approval without object identity is an ambiguous control token.

39. Approval Also Needs Valid Time

An approval can expire when underlying evidence, price or content changes materially.

Authority is contextual and temporal.

40. Completion Needs Evidence

A workflow step marked complete should correspond to an observable outcome: file saved, message sent, record created, page live or test passed.

Status should follow receipts, not intention.

41. Release Verification Is a Separate Step

“Publish requested” and “publication verified live” are different workflow states.

World return closes the loop.

42. Corrections Reopen Workflows

A finished article, payment or case can require correction after new evidence appears.

Completion should therefore support supersession, re-entry and audit history.

43. Workflow Versioning Protects Historical Meaning

If a process changes from five steps to seven, historical cases should remain interpretable under the version they actually followed.

Never silently apply today’s workflow semantics to yesterday’s event log.

44. Workflow Tokenisation Audit

What real process is being represented?
What counts as one step or action?
What states exist?
Which transitions are allowed?
What decisions create branches?
What roles and authorities are attached?
How are handoffs represented?
How are waiting and duration measured?
What stable case ID groups the events?
What exceptions, retries and loops exist?
Which activities can run in parallel?
What deadlines or escalation conditions apply?
What schema or workflow version applies?
What evidence proves each completed step?
Can the final state return to source event records?

45. What Students Should Remember

Workflows are representations of real activity.
Steps, actions and states are different token scales.
Decisions create branches and dependencies.
Roles and authority belong to process context.
Waiting, exceptions and retries are part of the workflow.
Event logs show observed work, not necessarily the complete process.
Approved and completed are different states.
Workflow versions preserve historical meaning.

46. The Deep Principle

A workflow token gives a process a machine-visible boundary: this action happened, this state is true, this decision was made, this authority moved the case forward.

Good workflow tokenisation does not merely describe the happy path. It preserves authority, exceptions, waiting, evidence and the exact state of work so the process can be understood, audited and safely continued.