Many things feel complicated because nobody can answer a basic question:
What state is this in right now?
The form is “sort of done.”
The repair is “being handled.”
The student “kind of understands” the topic.
The booking is “probably confirmed.”
The project is “almost ready.”
Ambiguous state creates ambiguous action.
Quick Read
In one sentence: state machines simplify life by defining a small set of meaningful states and the conditions that move an object from one state to another, so nobody has to reconstruct context from memory every time.
Finite state machines are used in software, electronics, robotics and workflow systems because behaviour depends not only on the event that just occurred, but also on the system’s current state. A door receiving “open” behaves differently if it is locked than if it is already unlocked. A workflow receiving “approved” behaves differently if it is still waiting for review than if it has already been cancelled.
Daily life is full of the same logic.
The value is not turning families into software.
The value is making relevant history explicit.
State is the smallest useful summary of what has happened so far that changes what may happen next.
State Machines Are Different From Queues
Queues order waiting work.
State Machines define the condition of each work item.
A repair can be:
reported → diagnosed → scheduled → in repair → waiting for part → verified → closed.
Several repairs may sit in a queue, but each has its own state.
State Machines Are Different From Closure
Closure gives work a trusted end state.
State Machines define the whole path, including intermediate states.
Closure owns “done.”
State machines own the legal road to done.
The Five Parts of a Useful State Machine
- Object: what are we tracking?
- States: what meaningful conditions can it occupy?
- Transitions: what moves it between states?
- Guards: what must be true before a transition is allowed?
- Terminal states: how does the process end?
Keep the number of states small enough that ordinary users can understand them.
Node 1: State Machines for Household Administration
A school form can move through:
received → needs action → signed → submitted → acknowledged → closed.
Now “Did we do the form?” becomes a state lookup rather than a memory contest.
If no acknowledgement arrives, the process does not pretend to be closed.
Node 2: State Machines for Student Learning
“Weak topic” is too vague.
A learning repair can move through:
detected → diagnosed → prerequisite repair → guided practice → independent practice → delayed retrieval → verified → maintenance.
Different states require different actions.
A detected weakness needs diagnosis.
A diagnosed misconception needs instruction or targeted practice.
A recently correct topic needs delayed retrieval, not immediate repetition forever.
State prevents the student from treating every problem as the same kind of problem.
Node 3: State Machines for Purchases
A significant purchase can move through:
need identified → criteria defined → researching → shortlisted → decided → ordered → received → verified → closed.
This reduces duplicate buying and endless comparison.
Idempotence becomes easier because the system can recognise whether the same purchase is already in progress.
Node 4: State Machines for Repairs
A repair is rarely just “open” or “done.”
Useful states may include:
- reported;
- diagnosing;
- awaiting quote;
- scheduled;
- waiting for part;
- repair complete;
- verification pending;
- closed.
Now a waiting repair does not consume the same active attention as one requiring action today.
Node 5: State Machines for Projects
Projects become clearer when progression has gates.
idea → scoped → approved → active → blocked/waiting → verification → complete → archived.
A project should not become active simply because someone mentioned it.
The transition from scoped to active can require a capacity guard:
WIP slot available + owner named + first checkpoint defined.
This links state machines to Work-in-Progress Limits.
Node 6: State Machines for Communication
Messages create confusion when “sent” is mistaken for “resolved.”
A request can be:
drafted → sent → acknowledged → accepted → in progress → answered → closed.
Each state changes what the sender should do next.
If acknowledged, do not keep sending duplicate reminders.
If unanswered past threshold, escalate or reroute.
Node 7: State Machines for Overload
Capacity itself can have states.
normal → stretched → overloaded → degraded mode → recovery → normal.
Different states trigger different policies.
In stretched mode, tighten rate limits.
In overloaded mode, shed lower-value demand.
In degraded mode, protect minimum viable function.
In recovery, restore capacity before restoring every old commitment.
Node 8: State Machines for Temporary Rules
A temporary arrangement can move through:
proposed → trial → active temporary → review due → renewed / redesigned / retired.
This makes Sunset Rules explicit rather than aspirational.
Transitions Need Guards
States are useful only if transitions have meaning.
Do not move a learning topic from “practised” to “mastered” because the worksheet is complete.
Require evidence.
Do not move a project from “active” to “complete” because work stopped.
Require completion criteria.
Do not move a submitted form to “closed” without acknowledgement if acknowledgement matters.
Guards prevent wishful state transitions.
State Machines Need Exception States
Real systems do not always follow the happy path.
Include states such as:
- blocked;
- waiting;
- cancelled;
- escalated;
- failed verification.
This prevents exceptions from being hidden inside vague labels such as “in progress.”
State Machines Need Observability
A state that exists only in someone’s head is fragile.
Observability makes current state visible to the people who need to act.
State Machines Need Runbooks
Runbooks explain how to execute important transitions.
The state machine says:
blocked → escalated.
The runbook says how escalation actually happens.
The Reverse Test: What Illegal Transition Could Cause Damage?
Ask what should never happen directly.
Detected weakness → mastered.
Idea → active project.
Payment requested → paid twice.
Temporary rule → permanent without review.
These are missing guards.
The Rotation Test: Do Different People See Different States?
One person thinks the task is “waiting.”
Another thinks it is “done.”
That is not merely a communication problem.
It is a state-consistency problem.
Shared systems need shared state names.
The Time Test: Are the States Still Useful?
Processes evolve.
A state that once mattered may become unnecessary.
Two states may collapse into one.
A new exception may deserve its own state.
Do not preserve complexity merely because the diagram once looked elegant.
State Machines for Students
- Detected weakness.
- Diagnosed cause.
- Repair active.
- Retrieval pending.
- Verified.
- Maintenance.
State Machines for Families
- Received.
- Needs action.
- Waiting.
- Submitted.
- Acknowledged.
- Closed.
State Machines for Work
- Scoped.
- Approved.
- Active.
- Blocked.
- Verification.
- Complete.
- Retired.
When State Machines Fail
- Too many states: the model becomes harder than the work.
- Vague states: labels such as “mostly done” carry no operational meaning.
- No guards: work advances without evidence.
- No exception states: blocked work hides inside active work.
- Private state: different people hold different versions of reality.
- No terminal state: work never genuinely closes.
- Stale model: states outlive the process they describe.
A Seven-Day State-Machine Experiment
- Day 1: choose one process currently described with vague words.
- Day 2: define five or fewer meaningful states.
- Day 3: define legal transitions.
- Day 4: add evidence guards.
- Day 5: add waiting, failure or escalation states where needed.
- Day 6: make current state visible.
- Day 7: remove any state that does not change what happens next.
Further Reading and Evidence
- Finite-state-machine literature in software and embedded systems.
- MathWorks Stateflow documentation on states and transitions.
- eduKateSG: How to Simplify Life | Closure.
- eduKateSG: How to Simplify Life | Runbooks.
Final Thought: Ambiguity Is Often a Missing State
When nobody knows what happens next, first ask whether anybody knows what state the work is in.
Name the state, define the legal next move, and much of the apparent complexity collapses into a path.