Formats

How to verify an AI-generated video was delivered by a Sume run

Before you count a Sume run as delivered, check status and primary_output_url, read filled_by, and probe the file. Here is what Sume checks, and what it skips.

5 min readSume
All posts

To verify that a Sume Format run really delivered its AI-generated video, check that the receipt is completed with a non-null primary_output_url, read output_schema.filled_by to see who wrote the structured output, and then probe the file itself. The docs say ffprobe on primary_output_url takes two seconds and is the only thing that distinguishes an assembled cut from a clip that is shaped like one.

The checks below come from Sume's Structured output and Errors and spend pages and the API reference, read on 2026-09-26. Binding the schema itself is covered in Sume Format structured output.

What should an automated check look at first?

The docs address exactly this case, scoring runs automatically in a smoke matrix, a partner integration, or a dashboard. Read the receipt in this order:

  • status is completed. primary_output_url is null on every failure, so if (run.primary_output_url) is a safe test for “the deliverable exists” and cannot be fooled by a partial.
  • output_error is null. Check it before you read output.
  • output_schema.filled_by is agent or projection. It is absent when output is null, and for the built-in schema.
  • The file behind primary_output_url is what you expect. For video, read the file rather than the number beside it.
  • Keep the artifacts[] metadata with your verdict: each file carries content_type, size_bytes, width, height, duration_ms, and checksum_sha256.
RUN=$(curl -sS "https://api.sume.com/v1/format-runs/$RUN_ID" \
  -H "Authorization: Bearer $SUME_API_KEY")
echo "$RUN" | jq '{status: .data.status, primary: .data.primary_output_url,
  filled_by: .data.output_schema.filled_by, output_error: .data.output_error}'

What does filled_by tell me about a run?

With agent, the run submitted your object during its turn; with projection, a post-run pass rebuilt it from the run's generated media and closing text. For QA, one pattern matters: the projection never sees your input, so titles, descriptions, or ids that come from the brief come back null while the media fields are full.

filled_by: "projection" with null prose is the shape of a run that stopped early, not of a Format that forgot to write copy. Treat it as a reason to probe the video before you ship it.

What does Sume check before output reaches me?

Every custom output goes through a gate. A run either returns output that matches your schema with real media URLs, or returns output: null and says why. It never returns a schema-shaped guess. Over the API a projection failure is a run failure, and media the run did not produce shows up as output_schema_unsatisfied with details.rejected_urls[] (the first 10).

The output gate, from Structured output, read 2026-09-26.
CheckWhat must holdWhat it catches
URLs, first passEvery http(s):// string anywhere in the object, at any depth, exactly equals media this run produced.A well-formed, plausible media.sume.com URL the run did not produce.
URLs, second passThe url of every SumeMediaFile-shaped value is collected whatever it contains.A placeholder such as "none" or "".
Generated onlyThe set holds media the run generated, not files it merely uploaded.An upload's URL in a schema field, which takes the whole output with it.
DurationsA duration_ms agrees within 10% with the length the ledger recorded.A length describing a different file.
Whole vs partsThe assembled file is not one of its own parts.Two or more succeeded parts, and a video outside every part reusing one of their files.
SchemaThe object validates against your output_schema.Any shape violation.

What does Sume not check?

Beyond the checks in that table, the gate checks nothing. Ids, labels, captions, and counts are read out of the run's media metadata and closing text by the projection pass. They are grounded in what the run reported, not verified against it, so treat them as the run's own account of its work rather than as measurements.

  • A duration_seconds number you declared yourself is written by the projection. The duration_ms on the media file is the checked one.
  • Where the ledger recorded no length, nothing is checked: null means “not measured”, not zero.
  • If you would rather probe on Sume's API, video inspect reads one media.sume.com clip already owned by the workspace, and its probe and stills are unbilled.

Which failure codes mean the video was not delivered?

These codes fail the run, so primary_output_url stays null:

  • deliverable_missing: the Format declares media in io.output_kind, and this run made none.
  • agent_reported_failure: the run itself reported that it did not deliver, for example media slots reporting failed or stand-in, or audio or a still under a video key.
  • incomplete_assembly: the run hit its time limit with generation jobs unfinished, so the delivered media is not everything it paid for.
  • unattended_blocked: assembled_deliverable is false, because the harvested media are intermediates, not the finished cut.
  • Every other code, and when to retry: Sume Format run failure codes.

Sources

Related posts

Written by Sume