Iterate and show

You called your model by name and watched it answer with your own weights. That's the software chain proven. This chapter is about making the model better — and proving it's better, which is the harder half.

Check the model before the arm moves

The first evaluation happens with no arm in the room. An open-loop check drives the model exactly as you would — same instruction, same wire — but with the hardware callbacks mocked, so it exercises the whole serving path without a single motion. It confirms the model loads, answers, and returns action chunks of the right shape. It doesn't tell you the model is good at the task; that still needs the arm. What it catches is the broken-plumbing failures, cheaply, before you spend a rollout on them.

Parity is the real prize

"It trained" is a low bar. The question that matters is whether your pipeline is faithful — whether the model our stack produced behaves like one trained on the reference stack from the same demonstrations. The way to answer it is parity: train the same demonstrations on the research team's own stack in parallel, and score both models on identical held-out frames. Agreement means our pipeline is provably faithful. Divergence means a bug was found before a customer could hit it. That comparison — not the loss curve — is the result worth reporting.

Fix what misses, then show the win

When you run it on the arm, note where the model still fails: the grasp that slips, the placement that misses. Those misses are your next demonstrations. Re-record them, add them to your dataset, and run the loop again from Record. Each pass targets what the last one got wrong.

Give each pass its own dataset name — roll_the_dice_v2, _v3 — since a name, once uploaded, is taken for good. The version trail is a feature: every pass trains its own model, and you can call any of them by name to compare.

When it works, capture it. The recording of your robot doing the thing it learned is the artifact you share.

Recording slot — poster pending

→ Call the model — the open-loop check runs the same call path with the hardware mocked.¹

That's the whole loop — drive, record, upload, fine-tune, call, iterate. The next skill you teach the arm starts back at Drive.