[IDLE] →💧 [PUMPING] →⚠️ [FAULT]

Three bottle caps laid on the ground with chalk arrows between them, each arrow labelled with what causes the move.

🎒 What you need

four or five bottle caps and chalk
a real system to model: a borehole pump, a traffic light, a mobile-money transaction
paper for your final diagram

✋ Do this

Choose a borehole pump controller. List its states on separate caps: IDLE, PUMPING, TANK FULL, FAULT.
Lay the caps out with space between them and draw an arrow for every legal move. Label each arrow with its trigger: 'button pressed', 'float switch high', 'motor too hot'.
Now find an illegal move. Can you go from IDLE straight to TANK FULL? No. Cross that arrow out — the arrows you refuse to draw are what makes the machine safe.
Play it: a friend calls out events at random and you physically move a stone from cap to cap. Any event with no arrow is simply ignored.
Add the awkward one: what happens if power fails mid-pump and comes back? Which state should it wake in? Argue it, then decide and draw it.
Copy the finished diagram onto paper. That drawing is a genuine engineering document and it is what you would code from.

💡 Why it works

State machines are how real controllers stay predictable, from washing machines to lift doors to mobile-money flows. The value is not the states, it is the transitions you deliberately do not allow — that is how you guarantee a pump cannot run dry or a lift cannot open between floors. Load-shedding makes the power-fail transition a genuinely important design question here, not a hypothetical one.

🔥 Challenge

Model something with at least six states — a matatu fare collection, a maize mill, a phone charging from a solar panel. Find one transition everybody forgets, then add it.

📖 New words

stateone distinct situation the system can be in at a moment

transitiona permitted move from one state to another

eventthe thing that happens and triggers a transition

🔁

State Setter

Tap when you have finished this module.