Keep this light. No grid set-up yet. Stand near the door and give one deliberately vague instruction such as Go over there, then ask why a robot would get stuck. Collect two or three pupil ideas about what was missing (direction, number of steps, when to stop).

Nature of STEM: Technologists write precise steps before they touch a device. Today's unplugged work is the same thinking pupils will need when they write code later.

Project only the short board version (algorithm and bug). Keep this tight so the fail-then-fix model always fits. Decomposition and debugging are named later, after groups have done the floor and desk runs.

Anchor the path question: Before you ask for the first step, stand at the demo floor grid (or on a few taped squares). Point clearly to the start square, the goal square (two ahead and one left from the robot's facing), and the path between them so every pupil can see the same short journey. Do not ask the question while the grid is still empty or off to the side.

Worked example (model this aloud once — mandatory before groups write)

Use the demo floor grid. Think aloud through one full fail-then-fix cycle only:

• I wonder: Can I write steps that get from start to the star without guessing?
• I predict: Forward, forward, turn left, forward should land on the star.
• I test: Act the steps yourself (or a volunteer robot who only obeys the words). Deliberately leave out the turn so it fails once.
• I observed: The robot went past the turn and hit the wall.
• I think: The bug was a missing turn left after the second forward. Add that step and try again. It works.

Misconception to head off: Pupils often write "go to the star" as one step. Allow only forward, turn left, turn right. Vague steps are not allowed because a robot cannot interpret them.

Do not teach all four terms here. After the group runs, label what they did as decomposition and debugging in the share step.

Setup (matches materials_needed)

Aim for groups of three or four. One demo floor grid at the front for your earlier model and an optional share run only. Every group works at its own desk grid mat with a small robot token, start/goal markers, one obstacle, and a set of command cards. That way every group writes, predicts, runs and debugs in the same 20 minutes. The floor grid is not a queue for group work.

Robot faces a fixed start direction on every grid. Only the three commands are allowed.

How to run it

• Assign jobs out loud: writer, reader, robot, checker. If a group has three pupils, combine writer and checker (or reader and checker). Rotate jobs after one successful run if time allows.
• Give each group the same short path type: start and goal marked on their desk mat, one wall square they must not enter.
• Writers lay instruction cards in order before anyone moves the token.
• Reader says one command at a time. Robot moves the desk token literally — wrong card means into the wall or off the grid.
• When it fails, freeze. Checker names the step. Change only what is needed, then re-run from the start.
• At the end of the 20 minutes, groups leave their working card sequence laid out (or take a quick photo if useful). The journal write comes next, while the cards and memory are still fresh. Do not stop mid-run for full journal writing.
• Optional: invite one group to replay their working sequence on the demo floor grid for the class.

Key questions

• Which step caused the bug?
• Did you change one thing at a time, or rewrite the whole plan?
• Could someone else follow your cards without asking what you meant?

Differentiation

Simpler path: three forwards and one turn. Stretch: add a second turn or a longer route around the wall. Fast finishers write a second algorithm for a new goal square on the same mat.

Fold the watchers in: When one group runs on the floor demo, ask the class Are they right so far? What would you predict for the next step? Watching is real participation — no parallel busywork sheets.

Safety: Walk only on the floor grid, no running. Tape edges can trip — step inside squares. Keep bags and chairs clear. Desk tokens stay on the table.

This is the paper recording beat, straight after the desk-grid runs so the fail-and-fix details are still fresh. Pupils use the Investigation Journal page. Cards should still be laid out on each desk as evidence.

Circulate and check:

• Steps are only forward / turn left / turn right (or clear equivalents), in order.
• The bug is named as a specific step, not "it didn't work".
• The fix is written as the changed step or inserted command.

If a group's first sequence worked first time, ask them to record a second challenge on the same mat where they deliberately introduced and then fixed a bug.

Do not invent extra columns or boxes on the journal page. Ask only for the working algorithm and the bug note the page is built to hold.

Drive algorithm-sequencer on the IWB in explore mode. Pupils call out the order; you drag the command blocks.

Screen grid is 5 by 5 with a wall — different layout from the desk 4-by-4 mats. Same three commands and the same debug habit, not the same path. Say this once so nobody tries to copy their desk sequence onto the board.

Exact layout on screen (so you can drive it without guessing):

• Grid: 5 by 5 squares.
• Start: column 0, row 2 (left side, middle row), facing east (toward the right).
• Star (goal): column 4, row 2 (right side, same row).
• Wall: column 3, row 2 (blocks the straight path, so the robot must go around).
• Commands: forward, turn left, turn right only.

One working route example for you (north side, not to show first): forward, turn left, forward, turn right, forward, forward, forward, turn right, forward. Equivalently south side: forward, turn right, forward, turn left, forward, forward, forward, turn left, forward. Both clear the wall column before turning back onto the goal row. Run once with a deliberate bug (for example only forwards along the middle row so it hits the wall) so the class practises debugging aloud. Then rebuild a working sequence together.

Prompts: Where is the bug? How would you fix it? and What is the smallest change that could work?

Link back to the desk grids: same three commands, same need for precision, same debug habit.