Same ad Format, new model: log three receipt fields on every run

Short answer

To keep the same ad format when a model changes, keep calling the same Format and log three things from every receipt: format.version, the model that ran, and the name of the output_schema you bound. The Format holds the recipe, and the model field on a run chooses only the orchestrator, not the image or video model the Format's tools use. So a new model name in your request does not rewrite the ad.

The orchestrator defaults to gpt-6-sol. Each receipt shows the model that actually ran, which can differ from what you asked, so log the receipt rather than your request.

What changes and what does not

The table separates the layers, read 2026-10-08.

Log it

Pipe the receipt through jq and keep one line per run. Add the run id so a later regression can be traced back to the exact version. This example prints the fields that matter, and the shell variables are placeholders.

curl -sS "https://api.sume.com/v1/format-runs/$RUN_ID" \
  -H "Authorization: Bearer $SUME_API_KEY" \
  | jq '(.data // .) | {id, status, version: .format.version, model, schema: .output_schema.name}'

Compare before you switch

When you move the orchestrator to a new model, run the same input through both for a small batch with a low spend cap, then compare the outputs and the format.version side by side. If the versions match and the outputs differ, the difference came from the orchestrator. If the versions differ, someone edited the Format.

Because format.version is pinned per run, a receipt from last month still names the recipe it used, even after you edit the Format.

• Keep Idempotency-Key values distinct per comparison arm.
• Use the same output_schema so results are comparable.
• Do not infer the media model from the orchestrator name.

When a result looks off

Read the receipt before blaming the model. A skipped step, a pending job or a missing primary output has its own error code, and each points to a different fix. Continue a run with previous_run_id instead of firing a fresh one when the work was nearly done.

Three failure modes

First, a changed format.version with no one remembering the edit. Second, a different orchestrator with the same version, which shows up as tone or ordering drift. Third, a schema renamed so old and new outputs cannot be diffed. Logging all three fields makes each one visible in a single query.

A fourth, quieter case: the model on the receipt differs from the one you requested. Alert on that mismatch rather than on the request.

Add this check to your runbook and run it on a schedule, not only after an incident. The cost is a few read requests, and the rate limits are far above what it needs: even the Free plan allows 120 writes and 4,800 reads per minute. Keep the output with the date, so you can show later what the system looked like when a question came up.

• Store receipts for as long as you store the ads.
• Add a weekly diff of the three fields.
• Treat these as working notes you can adapt: the figures are from the Sume docs read on 2026-10-08, and the arithmetic is yours to rerun with your own numbers.