Lesson 05 · 15 minutes · Preparation concept

Reasoning proposes.
Supervision decides.

Your next win: explain why a fluent visual-language response cannot directly move a robot.

The visual planner and supervisor are planned M2 work. This is a design lesson based on the accepted architecture, not a claim that model execution exists today.

Three jobs, three boundaries

ComponentQuestion it answersMay not do
Visual plannerWhat supported step fits the instruction and images?Invent a motor command.
Action policyWhat bounded joint targets fit this skill?Skip limits or ownership.
SupervisorCan this step run, recover, or stop?Declare success without evidence.

The supervisor owns prerequisites, timeouts, current arm ownership, cancellation, and recovery count. It validates a planner response against supported skills before a policy sees it. A clear stop with an explanation is a valid outcome when the scene or request cannot be handled safely.

A planner returns an unsupported step. What happens first?

Recovery needs a budget

Observe
fresh camera state
→Try skill
bounded action
→Check result
success or fault
→Recover or stop
record outcome

The plan permits at most two recovery attempts for a failed step. Each attempt requires fresh observations; stale images can make a plausible retry dangerous or meaningless. Cancellation clears queued actions so an old plan cannot resume after a new instruction.

What should a recovery use before retrying?

Practice: write a one-sentence operator explanation for “fork missing after two recovery attempts.” Include what was observed, what was tried, and why motion stopped. Ask the agent to critique it.

Primary reading: the project’s architecture and the Qwen3-VL model card for the proposed visual component.