How we grade a half-working robot

The most common failure mode in a build session isn't a mistake, it's a shrug. A robot doesn't move, the student doesn't know why, and the honest answer is they stopped debugging once it looked hopeless. That's the moment the rubric is actually built for.

We score three things: whether the build matches the intended design, whether the student can trace the fault to a specific cause, and whether they can describe what they'd try next. A robot that doesn't move but comes with an accurate diagnosis outscores one that moves but nobody can explain.

This produces some uncomfortable grading sessions early on, because it means a demonstrably broken project can still be a strong one. Parents occasionally ask about this directly, and the answer we give is the same one in the rubric: we're assessing engineering reasoning, not whether the demo goes well on the day.

It also changes how instructors run the room. Instead of racing to fix a stalled group before time runs out, the better move is often to sit with them and ask what they've already ruled out — which takes longer, and teaches more.

The rubric doesn't ask whether the robot works. It asks whether the student can explain why it doesn't — which turns out to be a harder and more useful question.