A system is easier to understand when we stop asking only what it is doing and ask what state it is in.
A lift can be idle, moving, aligning, doors opening, doors open, doors closing or faulted. A parcel can be ordered, allocated, picked, packed, dispatched, in transit, out for delivery, delivered or returned. A legal case can move through filing, review, hearing, decision and appeal. A learner can move from unfamiliarity to recognition, guided performance, independent retrieval and flexible transfer.
The language of state machines gives us a disciplined way to describe these changes.
A state machine represents a system as a set of possible states and the rules that determine how it may move from one state to another. In eduKateSG’s How X Works library, it is useful because it turns vague process language into explicit conditions, transitions and memory.
State Means “What Is True Now?”
A state is a compact description of the conditions that matter for what the system can do next.
For a door, “open” and “closed” may be enough. For a bank transaction, state may include authorised, pending, settled, reversed or failed. For a railway, the relevant state can include position, speed, route authority, signal aspect and door condition.
The right state representation is therefore a model. It keeps the information necessary for the next decision and ignores details that do not matter for that purpose.
Events Ask the System to Change
An event is something that may trigger a transition.
- a passenger presses a lift button;
- a sensor reports that a train reached a location;
- a customer submits a payment;
- a teacher asks a learner to retrieve a method;
- a regulator receives an application;
- a timer expires.
The event itself does not guarantee change. The current state and the transition rules decide whether the request is valid.
Transitions Connect One Valid State to Another
A transition is the change itself.
“Packed” becomes “dispatched.” “Doors closed” becomes “moving.” “Application received” becomes “under review.” “Guided solution” becomes “independent attempt.”
The transition matters because it tells us what changed, not just what action was attempted.
This connects directly to How Change Works: change becomes analysable when we can name the old state, the new state and the mechanism that connected them.
Guards Decide Whether a Transition Is Allowed
A guard is a condition that must be true before a particular transition can occur.
The train may move only if doors are confirmed closed and movement authority exists. A bank transfer may proceed only if the instruction is valid and required controls are satisfied. A student may move into a more independent task only after enough evidence shows that the prerequisite is usable.
Guards are one practical implementation of the precondition logic explained in How Preconditions Work.
Actions Happen During or After Transitions
A state machine often needs to do something when a transition occurs.
When a parcel changes to dispatched, a tracking event is recorded. When a lift enters moving state, doors remain locked and the motor profile changes. When an application becomes approved, a downstream workflow may be released.
The action changes the world. The state records what the world should now be understood to contain.
Memory Is What Makes State Useful
Without memory, every event would have to be interpreted as if nothing had happened before.
A transaction system remembers whether a payment is pending or settled. A ticketing system remembers whether a case is open or closed. A learner’s record may remember which skills were demonstrated and which remain unstable.
This memory can live in software, paper records, physical position, institutional status, biological configuration or human memory. The implementation changes; the logical role is the same.
Why State Machines Reduce Ambiguity
Natural language can hide contradictions.
A team may say an item is “done” when one person means “my part is done,” another means “the customer received it,” and a third means “the account is settled.”
A state machine forces the organisation to distinguish these states. That makes ownership, evidence and handoffs clearer.
Not Every State Is Equally Good
State machines describe possibility. They do not automatically tell us which states are desirable.
A system can have normal, degraded, failed, recovering and safe-shutdown states. Some are preferred, some tolerated temporarily and some prohibited.
This makes state design closely related to reliability and thresholds. The system needs rules for when it leaves normal operation and what it should do next.
Failure States Should Be Designed, Not Discovered by Accident
Mature systems often define failure states in advance.
- degraded: some function remains but capacity or quality is reduced;
- safe stopped: the system gives up function to protect safety;
- retryable failure: the operation can be attempted again;
- irrecoverable failure: manual intervention or redesign is required;
- recovering: repair is complete locally but full return has not yet been verified.
These distinctions prevent “error” from becoming one giant bucket that tells operators almost nothing.
Worked Example: A Lift
Consider a simplified lift state machine:
- Idle at floor.
- An event arrives: call request.
- Guard checks: doors closed, no fault, destination valid.
- Transition to moving.
- Sensor event: destination floor reached.
- Transition to aligning.
- Guard checks alignment and safety.
- Transition to doors opening, then doors open.
If a door sensor disagrees, the normal transition may be blocked and the lift enters a fault or retry state.
The value of the model is not that lifts literally contain a labelled diagram. It is that the state-machine view makes invalid transitions visible.
Worked Example: A Parcel
A parcel can be ordered, allocated, picked, packed, staged, dispatched, in transit, at destination depot, out for delivery and delivered.
Now ask: can “delivered” occur directly from “packed”? If the system allows that transition without extraordinary evidence, the state model is too loose.
State modelling therefore helps audit data quality as well as operations. Impossible histories reveal bad records or broken rules.
Worked Example: Learning
Learning should not be reduced to a rigid machine. Human cognition is richer and less deterministic. Yet state language can still clarify instructional decisions.
A learner may be unfamiliar with a concept, recognise it with support, reproduce a method under matching conditions, retrieve it after delay and finally transfer it to a novel problem.
The teacher should not confuse one state with another. Recognition is not independent retrieval. Correct performance immediately after explanation is not necessarily durable learning.
State thinking helps us ask what evidence justifies the transition claim.
State Explosion Is a Real Problem
If we try to represent every tiny detail as part of state, the number of combinations becomes enormous.
This is called state explosion. The model becomes too complicated to reason about.
The cure is thoughtful abstraction. Keep the variables that change what the system can do next. Put unrelated detail outside the state representation.
This is another reason system boundaries and state design belong together. Both decide what the model must remember and what it can safely ignore.
Distributed Systems Have More Than One State Story
A single machine may maintain one authoritative state. A distributed system is harder because different components can hold different views of what is true.
One service says the order is shipped. Another still shows packed. One bank has accepted a payment while another has not yet reflected settlement. One agency has updated a record while a downstream system remains stale.
Now the problem is no longer only transition design. It is synchronisation and reconciliation — later articles in this series.
The Backward Test
To test a state machine, start from a claimed final state and ask which previous states could validly lead there.
- Choose a final state.
- List the transitions that can enter it.
- Identify the required guards.
- Ask what evidence proves each guard was true.
- Trace the valid predecessor states backward.
- Look for shortcuts the model accidentally permits.
This is particularly good at finding hidden invalid paths.
A state machine is a map of what can be true, what may happen next and what the system must refuse.
Continue through the master How X Works hub. The next mechanism is guard conditions: the logic that decides whether an otherwise possible transition is permitted now.