# Descriptive transcript — Replanning, Timeouts, and Fallbacks

All visuals below are original simulation drawings. Times refer to the complete local MP4. No essential information requires color perception: labels, positions, gates and narration communicate the same distinctions.

## 0:00–0:09 · The doorway closes

**Visual:** A top-down delivery robot approaches a doorway. A cart travels left in the upper room, then down into the doorway. The robot decelerates before the stop line; a red X marks its old path as invalid.

**Spoken:** A delivery robot has a route. Then a cart blocks the doorway. Should it retry? First, stop the motion that the old plan allowed.

## 0:09–0:25 · Cancel is a request

**Visual:** A stationary robot is labeled motion OFF. Requested, accepted and canceled are separate boxes with a moving control signal. The replacement remains locked during the first two states; terminal confirmation does not turn motion back on.

**Spoken:** Inhibit motion and request cancellation. Cancel accepted is not canceled. Wait for the old action's terminal result before sending a replacement. A software acknowledgment does not prove the physical robot has stopped.

## 0:25–0:39 · Which clock expired?

**Visual:** Three separate clock rings labeled Reply, Progress and Cancel. One ring expires; three possible diagnostic causes remain unresolved, represented by short labels.

**Spoken:** A timeout means a deadline passed, not that the doorway is blocked. Server response, movement progress, and cancellation are different clocks. Preserve the error, timestamps, and action state.

## 0:39–0:52 · Wait, then re-sense

**Visual:** Robot stationary behind stop line while simulated elapsed time advances 4 to 7 seconds; cart clears doorway. Sensor sweep and checked route appear only after fresh evidence.

**Spoken:** Here is our simulation policy: wait three seconds, then inspect fresh evidence. The cart moves away. Check the route again; elapsed time alone is not permission to move.

## 0:52–1:07 · Verify before retrying

**Visual:** Three checks unlock one new action. Counter reads attempt 2 of 3 / retry 1 of 2. Robot follows the newly validated path through the clear doorway to goal.

**Spoken:** The old action has ended, the state is fresh, and the route is valid. Now dispatch retry one. Two retries means at most three attempts, including the original. It is a budget, not a target.

## 1:07–1:23 · Stop the retry loop

**Visual:** Two alternatives are compared: a persistent blockage ends recovery with zero retries, while a separate ledger illustrates an initial attempt plus two justified retries. Stop, evidence and human help form the handoff.

**Spoken:** If the doorway stays blocked, stop early. If justified retries still fail, the budget or mission deadline ends the task. Keep motion inhibited and escalate with evidence. Clearing a map cannot remove a real cart.

## 1:23–1:36 · Accepted. Move now?

**Visual:** A stationary robot appears below separate cancel-accepted and terminal-result-missing boxes. WAIT or START is the retrieval question. A three-second counter gives time to decide.

**Spoken:** The server accepted cancellation, but no terminal result arrived. The doorway is clear. Should a new motion goal start? Pause and decide.

## 1:36–1:53 · Wait for the evidence

**Visual:** Three linked gates read INHIBIT, VERIFY and BOUND RETRIES. A cancellation timeout leads to escalation, not another dispatch. Narration links the principle to the failure-case lab.

**Spoken:** No. Keep motion inhibited. A clear route does not settle the old action's status. Escalate if cancellation times out. Test these failure cases in the lesson lab, and follow Humanoid Hub for robotics you can explain.

The three-second retrieval pause occurs before the answer. All time budgets are invented simulation values, not robot settings.