Log format.version on every bulk child: which recipe made which video

Store format.version from every child run receipt next to your SKU. Each run reads the package it started with, and a bulk queue dispatches items over time, so a long queue can span an edit. The queue receipt shows one format.version, but the per-run receipts are the record of what ran.

Where the version appears

The Format record carries version, which Sume bumps on every edit. The run receipt repeats it as format.version, and so does the queue receipt and the webhook payload. A Contents API commit returns the new version in its reply.

A small audit table

One row per child is enough. Join it on the run id you received.

• Columns: sku, queue id, item index, run id, format.version, package_sha at queue time, status.
• When a client asks why last week's videos looked different, compare versions before you compare prompts.
• Do not edit mid-queue unless you intend a mixed batch; if you must, record the edit time.

When the versions differ

If the versions in one queue are not all the same, someone edited the Format during the batch. Items dispatched before the edit read the old package and items after it read the new one, which is the documented rule that each run reads the package it started with.

To fix a mixed batch, re-run only the items from the older version, using fresh keys. Use the audit table to pick them instead of re-running the whole queue.

Keep the queue id as well. A queue is one batch in your records, and its status URL lets you rebuild the item list from the API if your own table is lost, since the queue returns every item with its index, run_id and status.

Store the receipt next to the delivered file, not in a separate log nobody opens. When someone asks months later why two videos differ, the stored version answers it in seconds.

Tradeoff

The version is a counter, not a diff. It tells you that something changed, not what. Pair it with your own copy of the package at each version, because the API cannot show history.