{"slug":"nvlabs-yam-runtime-artifacts","name":"yam-runtime-artifacts","description":"Use when inspecting YAM logs, videos, SAM3 overlays, observations, planner previews, function-call JSON, result files, or failure evidence.","long_description":"---\nname: yam-runtime-artifacts\ndescription: \"Use when inspecting YAM logs, videos, SAM3 overlays, observations, planner previews, function-call JSON, result files, or failure evidence.\"\n---\n\n# YAM Runtime Artifacts\n\nRun artifact commands from the Aspire real-robot workspace (`aspire/real`).\nAll `logs/**` paths below are relative to that directory.\n\nRuns write to `logs/_/`.\n\nArtifact inspection rule: tool return is not success. For physical debugging,\nthe two highest-value evidence sources are:\n\n1. `debug_events.jsonl`: what the robot was commanded to do, in order, with\n timestamps, arguments, durations, and errors.\n2. Video frames from `top.mp4`, `left.mp4`, `right.mp4`, and `bottom.mp4`: what\n physically happened before, during, and after those commands.\n\nDo not infer contact, grasp, drawer motion, collision, or success from JSON\nalone. Align command windows from `debug_events.jsonl` with extracted video\nframes. If videos are missing or corrupt, treat the run as weak evidence unless\nthe task is specifically recorder debugging.\n\nCore workflow:\n\n1. Validate recorder output:\n\n ```bash\n python3 -m json.tool logs//preview_recording_result.json\n ```\n\n Each needed camera should have `ok=true`, `ffprobe.ok=true`, nonzero\n `duration_s`, nonzero `nb_frames`, `backend=\"python\"`,\n `codec_name=\"h264\"`, and `pix_fmt=\"yuv420p\"`.\n\n2. Read the robot-command chronology:\n\n ```bash\n rg -n 'tool_start|tool_end|freespace_move|servo_ee_delta|set_gripper|get_robot_state' logs//debug_events.jsonl\n ```\n\n Use this to identify the exact windows for approach, close, contact, push,\n pull, release, retreat, and failures. Prefer actual tool arguments over\n script labels when deciding motion direction.\n\n3. Extract frames around those windows:\n\n ```bash\n mkdir -p /tmp/yam_frames\n for cam in top left right bottom; do\n for t in 0 10 20 30 40 50 60 70 80; do\n ffmpeg -hide_banner -loglevel error -y -ss \"$t\" \\\n -i \"logs//${cam}.mp4\" -frames:v 1 \\\n \"/tmp/yam_frames/${cam}_${t}.jpg\"\n done\n done\n ```\n\n Then inspect the relevant frames or make contact sheets. Always include\n frames before, during, and after the motion; a single final frame often\n hides whether contact was useful, transient, or accidental.\n\n4. Answer the physical question from the paired evidence:\n\n - Did the gripper actually reach the target, or only the planned pose?\n - Did the fingers capture the object/handle, or slide along it?\n - Did the object move relative to fixed scene features?\n - Did the gripper open before retreat or while still engaged?\n - Did the final state persist after release?\n\nSupporting artifacts:\n\n- `result.json`: final reward/success packet from `run_script.py`. It may wrap\n script details under `details` or `info`. Treat it as an index, not proof.\n- `stage_summary.md`: human-readable summary written by scripts that call\n `write_stage_summary`. Useful for compact config, final state, and\n `why_stopped`, but still verify against `debug_events.jsonl` and videos.\n- `task_result.json`: some older scripts write their own result packet here.\n Compare with `result.json` if both exist.\n- `exec.log`: process-level stdout/stderr and Python exceptions. Use this for\n import errors, uncaught tracebacks, and recorder startup/shutdown messages.\n- `run_