Format output rejects a scene clip in the final video field

If your output_schema has a list of scenes and a field for the finished video, a run cannot fill the finished-video field with one of its own scene clips. Sume rejects that receipt, so you get output: null with an output_error instead of a scene passed off as the show.

The rule is documented in Structured output under the heading about the deliverable not being one of its parts, read on 2026-10-02. This post walks through exactly when it triggers and how to write a schema that tells the truth about a partial run.

When does the check fire?

The check is narrow on purpose. It needs both conditions below. If either is missing it does nothing.

What is deliberately left alone?

A Format whose single clip really is the deliverable is untouched, because there are not two or more parts. A poster or thumbnail deliberately reused from a part is also untouched, because the reuse check is about the finished-video field standing in for the assembly.

This keeps the gate from punishing honest short formats. It only catches the pattern where a long Format failed to stitch its scenes and the closing summary pointed at scene one as if it were the cut.

How should I write the schema?

Make a partial legal. Every property still goes in required, so optional means a nullable union, and you leave minItems off arrays you want to receive partially, because it is enforced. Then let the assembled field be null when nothing was assembled.

{
  "type": "object",
  "additionalProperties": false,
  "required": ["full_video", "scenes"],
  "properties": {
    "full_video": { "type": ["string", "null"] },
    "scenes": { "type": "array", "items": { "$ref": "#/$defs/scene" } }
  },
  "$defs": {
    "scene": {
      "type": "object",
      "additionalProperties": false,
      "required": ["id", "status", "video_url"],
      "properties": {
        "id": { "type": "string" },
        "status": { "type": "string", "enum": ["succeeded", "failed"] },
        "video_url": { "type": ["string", "null"] }
      }
    }
  }
}

What does a run that could not assemble report?

The docs say an honest answer is available: report the parts you made and leave the assembled field null, or report the assembly's real status. Pair the schema with primary_output_key set to the assembled field. A run that fills scenes but leaves full_video null satisfies the schema, yet it ends failed with primary_output_missing, so it cannot be mistaken for a delivered show.

On a failed run primary_output_key and primary_output_url are both null, so if (run.primary_output_url) stays a safe test for whether the deliverable exists. The partial output and artifacts[] are still there.

How do I recover?

Branch on full_video for whether you got a show and on each scene's status for what to retry. To redo only the broken scenes, start a new run with previous_run_id set to the failed run, bind the same schema again (it is per run, not inherited), and keep a small generation_spend_cap_usd. The finished clips are on the thread and are not regenerated.

Sume does not verify the assembled file for you beyond these checks. For video, the docs suggest reading the file itself with ffprobe on primary_output_url rather than trusting a number beside it.

What to log when you score runs

On the projection path an empty text field is itself a signal. A run that stopped early shows as projection with null prose and full media fields, which is not the same as a Format that forgot to write copy.

• filled_by: whether the run submitted the object itself (agent) or it was rebuilt from leftovers (projection).
• Each scene's status and video_url, so the retry list is derivable without another call.
• primary_output_url presence, which is the safe test for a delivered cut.
• output_error.code, treating the set as open: new codes may appear, so branch on those you handle and fall through on the rest.

Why does Sume enforce this?

The structured output on an API run is meant to be a receipt you can trust without opening the file. Because the object is gated before it reaches you, a field called the finished video should never silently hold a single scene. The gate is also the reason the docs tell you to read the file for video: a clip shaped like a cut and an assembled cut look alike in JSON.

The check is separate from the URL gate and the duration check. The URL gate makes sure every URL was produced by this run. The duration check requires a duration_ms to match the artifact ledger within 10 percent when one was recorded. This rule covers the case where all URLs are real and all durations are fine and the field is still the wrong file.

What if my Format really has one clip?

Then there is nothing to confuse. A schema with a single video field and no parts is not affected, since the check needs two or more succeeded parts. The same goes for a poster that you intentionally reuse from a scene.

If your recipe produces scenes and an assembled cut, ask the recipe for both and make the assembled field nullable. Pair it with primary_output_key so a missing cut is a failed run, not a quiet success.