Format run scene status stand-in vs failed: which scenes to retry

If your Format run returns a list of scenes, give each scene a status enum of succeeded, stand-in or failed, then retry only the scenes that are not succeeded. Sume's own cookbook uses exactly this shape for a live-commerce show: full_video for the assembled cut, and scenes[] with a stable id, a role, a status and a video for each clip.

The values are yours to define, because the schema is yours. What Sume adds is a rule on the way out: when the accepted receipt of the run reports media slots as failed or stand-in, the run ends failed with output_error.code of agent_reported_failure and details.reason of slots_failed. The clips that did render are real and are on output and in artifacts[]. A retry does not generate them again (Errors and spend).

What each status should mean in your schema

Branch on full_video for "did I get the show" and on each scenes[].status for "what needs a retry". The Format docs say the same: the next turn continues the same conversation, and the finished clips are already in it.

Retry the bad scenes on the same thread

Send the id of the failed run as previous_run_id. Put the operator note in instruction and the machine-readable pointer in input. For two scenes use scene_ids. Use a new Idempotency-Key, because the old key is bound to the receipt you already hold, and send a cap so a retry cannot spend more than you planned.

curl -sS -X POST "https://api.sume.com/v1/formats/acme/live-commerce/runs" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: sheet-45-v1-retry-sc7-sc9" \
  -d '{
    "previous_run_id": "arun_...",
    "instruction": "Retry the selected scenes only. Keep every other scene and the voice track unchanged.",
    "input": { "scene_ids": ["sc_7", "sc_9"] },
    "primary_output_key": "full_video",
    "generation_spend_cap_usd": 8
  }'

Three limits to plan for

Do not put minItems on the scenes array if you want to read a partial ledger: Sume enforces it, and a 20-of-40 show would return output: null instead of the 20 clips.

• Pass the same output_schema on the retry that you used on the first run, so the new receipt has the same shape.
• The API refuses the continuation with 400 previous_run_not_resumable when the earlier run left nothing, 409 previous_run_not_terminal while it is still running, and 400 previous_run_format_mismatch if you address a different Format.
• A retry is a new take of the scene. If the words, the host or the product change, start a new production with new scene ids instead.