The Engine: generation, control, export

We present an engine for automatic storyboard generation, for campaigns built around mascot characters. Here's the I/O in brief. In: four manual inputs — the mascot pair (neutral reference image), the brand or object to promote, the script that describes the story, and the slogans — all chosen upstream, by the brand or its agency; everything else, the structured description file included, is generated. Out: N story variants, with a QA control mechanism, and export formatting matching the AD-serving/DCO platforms this generative engine plugs into. This post complements the worked example from the earlier post The grape harvest of Grappolotto and Foglina, adding more technical depth. The goal is to bring attention to the automatic self-correction loop that checks variants against a human-approved master storyboard (Chapter 05), the manifest's data structure and its final human sign-off (Chapter 06), and on to the formats and the formatting spaces per the specifications of a reference template (Chapter 07). Finally, in the last step, the batch of information for every shot is exported into the Manifest, according to the format agreed with the AD-serving/DCO platforms. A point which, from the market's point of view, is covered in more depth in the post DCO: One Pipeline, Many Products.

Where the engine sits. It is not the campaign. The brand or its agency decides the brand, the slogan, the cast and the setting, and calls the engine as a pre-production step: a creative lead or a campaign-operations person sends one job — a brief, a locked character pair, the background plates — either as an API request or as a JSON file, and gets back a pool of finished story variants. The story itself arrives in one of two ways: written by the brand's creative team, or drafted by the engine from the brief and then approved upstream; the engine never decides on its own which story runs. The pool then enters whichever dynamic-creative tool the client already runs today (DCO and the Agency Market covers how that hand-off works); the job and export formats are specified in DCO Engine: technical description.

What follows covers the whole engine, not a layer on top of something explained elsewhere: given a character pair and a brand's slogan, generate the story itself, not just its shots; run it through the loop that produces compatible variants for new slogans; and check and repair every shot with the generate → judge → correct loop the rest of this mechanism relies on. The product being advertised in the running example is a professional wooden waiter's corkscrew, shown below.

What Dynamic Creative Optimization is

Dynamic Creative Optimization (DCO) is the performance-marketing practice of generating many ad variants automatically instead of committing to one static creative, so a campaign can be tested and optimised at scale rather than designed once and hoped for. The goal predates generative AI by years — DCO has run on templated recombination since programmatic display advertising; what AI changes is which variants are affordable to produce and what each one can actually show.

What it does.

• Produces many variants of one campaign idea automatically — different slogans, different staging, different regional cuts — instead of committing to a single agency-approved version run everywhere.
• Tests those variants against real audience response and shifts spend toward whichever perform, instead of guessing upfront which creative will work.
• In its generative-AI form specifically, renders each variant as new imagery on demand, rather than recombining a fixed set of pre-shot photos or clips — the older, templated form DCO has used for years.

Who it's for.

• Performance-marketing agencies already running DCO at volume, who need a way to check every variant stays on-brand without reviewing each one by hand.
• Global CPG brands running one character or campaign across many regional markets, who need every localised variant to agree with the others on what "on-brand" means.
• AdTech and creative-automation infrastructure vendors, who build and sell this kind of pipeline to agencies and brands rather than running campaigns themselves.
• Large-scale UGC and co-creation campaigns, where the sheer review volume makes manual QA physically impossible rather than just expensive.
• Each of these four buyer profiles is worked through in detail, with real cases, in DCO: One Pipeline, Many Products.

What AI contributes today.

• Before generative AI, DCO meant recombining a limited set of pre-shot photos or clips into different arrangements — real variety was capped by how much had been shot in the first place.
• Generative AI removes that cap: each variant can be a new image or sequence, built to spec rather than selected from a fixed set, which is what makes a full new mascot story — not just a new crop or headline — a realistic variant to generate.
• That removal creates a new bottleneck of its own: nothing in generation itself guarantees a freshly generated variant is still on-brand and on-character. The generate → judge → correct loop described below exists to close exactly that gap — it is the actual contribution this post walks through, not the generation step on its own.

1. 01

   The product and the campaign's claim

   

   The object every variant in this post has to show correctly: wooden handle, hinged lever, foil cutter, spiral worm — de-branded, since the brand behind it is kept deliberately anonymous throughout this example, for copyright. It's a small, mechanically specific object — easy to get subtly wrong — which is exactly why it is a useful thing to put in front of the judge step described below. The claim built around it is a vineyard-brand one: wine marketing already leans on seasonal, narrative slogans rather than feature lists, which fits an engine whose actual job is restaging one story around a changing slogan — the two used further down are "…the harvest gives us a wonderful wine!" and "…raising a glass of wine!". One product, one claim, many compatible variants of it — that is the worked example the rest of this post follows.

1. 02

   The character pair, the product, and the background plates

   The reference campaign uses the same storyboard already seen in The grape harvest of Grappolotto and Foglina. The input the engine needs: one character pair in two images — the one with the two mascots isolated (neutral image) and the one with the mascots staged in the vineyard background plate — plus, when the campaign's product needs a locked visual identity of its own rather than a generic stand-in, its own separate reference image (the corkscrew case below). The pair's neutral image is taken as the reference, and it plays a double role, as we'll see in chapter 05 The judge in the loop:
   1. Identity reference — fixes the two characters' look: this is what D checks identity drift against (does the generated character actually look like Grappolotto/Foglina?).
   2. Staging reference — also fixes who stands on the left and who on the right as the canonical convention, the same one that later reappears as the LEFT:/RIGHT: field in the structured description file (Chapter 03, one field per beat) and that D rechecks for spatial alignment (Chapter 05: “confirming a character sits correctly on the LEFT: versus the RIGHT:”).
   The same logic applies to the product being advertised: once it has its own reference image, the generate→judge→correct loop checks its identity, position and context in every beat exactly as it does for the characters — not just that it's the right object (the wrong-object case in Chapter 05), but that it's staged the right way too. The settings for the other frames are obtained without needing any further input images, but from the description of the image itself, always using the neutral image of the two isolated mascots as the reference. The reference mascots can be generated (with the Google Gemini API, in this release) or commissioned from an outside service. That isn't the point of this post — the point is to show how easy it is to rely on a same-day setup, rather than a multi-week illustration commission.

3. 03

   The story as a structured description file

   The engine needs the campaign story in a structured shape, not free prose: one entry per beat (shot), each with its characters and their LEFT:/RIGHT: position, the background plate, the product or prop, the narrative role (opening, reveal, close) and any scene conditions, such as rain or sun. The campaign creator fills in none of this: there are only four manual inputs — the mascot pair in the neutral image, the brand or object to promote, the script that describes the story, and the slogans (if the brand has no script, the engine can draft one from the brief and a person approves it upstream). Everything else is generated: Claude (or whichever LLM is used) structures the script into the description file and fills in all its fields, and a person checks it rather than hand-writing it shot by shot. An example of the file, and the function that produces it, are in DCO Engine: technical description, chapter 02.

4. 04

   Variant types and orchestration: one cast, many compatible stories

   Two kinds of variant. Type A — script variants: each is a different story, written by a person as its own script (for example: Grappolotto and Foglina get married; later they have a child). Every script becomes its own description file, which then goes through the generate→judge→correct loop (chapter 05). This is what the first release covers. Type B — sub-variants: smaller episodes branching off a type A story, which the engine could propose automatically² (other little animals turn up; the child plays with the hens and the rooster gets jealous; a city cousin of Grappolotto arrives, running the grape cooperative's bank — stories in the style of 1950s–60s Disney). Each proposal would get its own description file, but only after a story-consistency check on the text, before any image is generated (see chapter 05). Type B is a future development, not part of the first release.

   Who orchestrates, in practice. The orchestration here isn't a hand-written, line-by-line control flow: it's a coordinating agent that launches one pass of the generate→judge→correct loop (chapter 05) per variant, handing each the same locked references every time — characters and product (chapter 02), background — and simply checks that every run comes back with the same cast and the same world, only staged differently.

5. 05

   The judge in the loop: A→D→E→D and its limits

   Each pass of the generate→judge→correct loop (A→D→E→D)¹ works from what is already fixed for that variant — its description file, the master storyboard (human-approved, the reference every variant is built and measured against), the character and product references (chapter 02) and the background plate — and produces its storyboard: same cast and setting, following the consistency rules fixed in chapters 02 and 03. The slogan comes along as supporting copy, but it does not build the storyboard: on its own, a slogan leaves the model too much room to invent scenes that don't fit together. The orchestration's job: keep every variant compatible — same characters, same world — while the staging follows its own description file, not the slogan.

   Two kinds of error, two different owners. The first: conformity errors and hallucination — identity drift, the wrong object, a deformed product, an extra character that doesn't belong in the cast. That's D's job, checked shot by shot against the spec and the master, and it's also D's strongest ground: research on using an LLM or VLM as a judge for image generation shows it aligns well with human judgment on clearly-failed outputs like these. D is weaker on fine spatial alignment — confirming a character sits correctly on the LEFT: versus the RIGHT: of a frame — which is exactly where the calibration below earns its keep. The second kind of error is a different problem entirely: the plot's semantic quality — does the story actually sell the brand? That's a creative-direction call made upstream, decided and signed off by a person when the master storyboard is locked, never a judgment D makes during the loop. For type B sub-variants (chapter 04, a future development) this call would not be left entirely to a person: a story-consistency loop, working like D but on the text before any image exists, would check each proposed sub-variant against the master storyboard and the cast rules, and send it back for rewriting if it contradicts them. It checks consistency, not persuasiveness: whether the story actually sells the brand stays a human sign-off. A stronger VLM raises generation quality, but it doesn't move this second line: conformity stays something D can check, the story's quality stays a human call.

   Calibration. In practice, this means the supervisor periodically re-checks a sample of shots D has already waved through — not a full review of everything. Say D keeps approving a shot where Foglina ends up on the left instead of the right: once that mistake shows up often enough in the sample, it becomes a calibration example — the image, the correct verdict, the reason — added to D’s prompt as a worked case to learn from. The sample also yields two numbers worth tracking: the agreement rate (how often D and the supervisor agree) and the false-pass rate (how often D lets a wrong shot through). Today this cycle — sample, measure, add the example — is done by hand; tracking it automatically from one release to the next is a later step, not part of this pipeline yet.

   An alternative mode: best-of-N. The default loop is pass/fail plus repair: D rejects a shot, E fixes only what was flagged. This release also offers another option: generate N candidates for the same beat and have a VLM rank them against the master storyboard, keeping the best one instead of repairing the single shot generated. Take the product-reveal beat, with Grappolotto and Foglina standing close together over the corkscrew: that’s exactly where a staging slip — an arm in the wrong place, the product tilted — is both more likely and easier to spot. Generating three or four candidates and keeping the cleanest one costs more API calls per shot, but it’s worth it on beats like this one.

   A real correction, worked through. A wrong-object case — the other conformity error D is built to catch, the product rather than the cast. For the campaign's hero shot — the one The grape harvest of Grappolotto and Foglina opens on, promoting one specific product, a professional wooden corkscrew — a first generation pulls a generic, rough-looking corkscrew out of the engine's own asset repository instead of the branded one the whole campaign exists to sell. D flags it against the master: the spec names that exact product, not a stand-in from the repository. E corrects it by regenerating the prop region with the correct corkscrew — same shot, same characters, same table. The corrected version is the one published as the campaign's hero image.

Weighed against a person doing the same check by hand:

• Pro — scale: checks every variant at the same standard, whether it's variant 1 or variant 400; a human reviewer's attention and standards drift over a long batch in a way the judge's criteria don't.
• Pro — speed: a defect is flagged and routed back for correction in the time it takes to run the loop again, not in the time it takes to reach the top of a review queue.
• Con — cost: every automated check is still an API call per shot, scaling linearly with volume; it isn't free just because no person is involved (cost detail in DCO: cost model).

What's still open. What's new at engine scale is the volume of judgments per run. But a master storyboard and a calibration loop fix consistency within one variant, not across a batch: nothing here checks variant 12 against variant 1 once both individually pass D against the master — an open "campaign auditor" role this pipeline doesn't yet solve.

The full diagram

1. Step 1: One character pair, plus two or three background plates — these keyframes can themselves be generated rather than commissioned.
2. Step 2: The story, automatically generated from the campaign subject by Claude (chat or API), structured as a description file — one entry per beat, with its characters, their position, and their narrative role.
3. Step 3: A loop that generates story variations: the description file, the character and product images and the background go in, with the slogan as supporting copy; orchestration produces compatible story variants, staged as the description file says. Details: The A→D→E→D loop and its judge-reliability caveat — strong on gross identity drift, weaker on fine spatial alignment — against the Pros of automating that check at scale compared with a human doing it by hand.
4. Step 4: Output: N generated-and-QA-repaired story variants for one brand — full beat-by-beat sequences, not single images. What N actually costs to produce — yield, refusal rate — is in DCO: cost model.
5. Beyond the engine — two aspects of export
6. Step 5: Formats and reserved zones: every approved shot is recomposed into the aspect ratios the ad formats will ask for, keeping the cast inside the frame and leaving clear the rectangle the template will occupy.
7. Step 6: Export: the batch becomes a structured manifest — one row per shot, format and slogan, with a unique ID, variant labels and QA status — plus the adapters towards the feed schema of the platform already in use.

6. 06

   Export: from pool to feed

   A pool of approved images is not yet something a dynamic-creative platform can read. The export layer covers that gap: it turns the run into a structured manifest, where every row is one deliverable unit — one shot, in one format, for one slogan. A six-beat story, with three slogans and four formats, produces 72 rows: exactly the multiplication that in an agency is still done by hand.
   
   There is one canonical manifest, and the adapters towards individual platforms are thin. The engine never writes one vendor's format directly: it writes everything it knows about the batch, and an adapter selects and renames the columns for the destination. Adding a destination means writing an adapter, not touching the engine. The first adapter follows the feed schema already described in DCO and the Agency Market: a unique ID per row, an image URL, headline and CTA text, an exit URL. Let's list the Manifest's fields:

   • asset_id — the identifier the DCO engine will use to call the image. The convention is to write them in this order — brand-story-slogan-beat-format — because when a report flags a problem, the ID already says where to look.
   • brand, product_line — the keys that hold a multi-product catalogue together (see DCO: One Pipeline, Many Products).
   • story, beat, narrative_role — where the shot comes from and what function it has in the sequence: opening, development, close. It matters because a CTA does not belong on an opening beat.
   • cast — who is in frame, so a batch can be filtered by character.
   • format, reserved_zone — the aspect ratio, and the rectangle the template can occupy without covering a face (chapter 07).
   • variant_labels — what the scene depicts: weather:rain, time:evening, occasion:birth. This is the conceptually decisive column: here we declare what the image is, never who should see it. The selection stays with the platform's rules.
   • qa_status — Quality control: passed first try, corrected, or discarded (with the discard reason). Discarded rows stay in the manifest for traceability, but never enter the feed.
   • review_status — the final human sign-off on brand and compliance, which stays a human signature.

   Two reports come out of the same manifest. The first is coverage: for every combination the brief asked for — slogan by label by format — is there at least one approved row? The mismatch has to show up before delivery, not after. The second is the batch account: rows generated, approved, discarded, and machine time spent. Those are the production metrics the overview page talks about.
   
   A design note: asset_id and variant_labels are also the hook that would later make it possible to read the platform's reports by ID and retire the low-performing variants.

7. 07

   Formats and reserved zones

   The same approved shot has to be exported in several aspect ratios — 1:1, 4:5, 9:16, 16:9 — as the ad platforms will require. The mechanical part is simple: crop where the content allows it, extend the background where a crop would hurt the cast or product, and have the judge of chapter 05 (the loop's automatic checker) recheck the reformatted frame, because identity has to hold after a crop or an extension too. The same information about where the characters stand enables the reverse operation, which is the one that counts most: composing the scene so that the rectangle where the template will write headline, price and CTA stays clear. A downstream tool cannot do this — by the time it receives the image the scene already exists, and useful information risks being covered for the viewer (see image below).

   For this to work the engine needs an input it does not have on its own: the geometry of the templates actually in use at the client — which rectangle, in which aspect ratio. In practice, reserved-rectangle staging is waiting for the template geometry of a real client to put it to the test. For the API-call counts, per-image costs and the config-table/description-file mechanics behind both stages, see DCO: cost model.

   

1. The A→D→E→D loop is the generate–judge–correct cycle the whole pipeline runs on, also described in DCO: One Pipeline, Many Products. A generates a shot against its structured spec. D, a Gemini-based VLM judge, checks the result assertion by assertion — does the LEFT: character still have its defining features, does the pose match the spec, and so on — and lists any defects by severity. E edits the shot to fix only what D flagged, without re-generating from scratch. D then rechecks the corrected shot, and the cycle repeats until it passes or hits a budget cap on retries. The loop runs once per shot, so a single story variant with several shots runs it several times. ↩
2. Today's diffusion/transformer models do more than follow the prompt's plain, name-only list: they describe a scene in far more detail, adding characters nobody mentioned for consistency with the setting (e.g. a farmhouse, a flock of grazing sheep, a village fair, and so on). A similar idea could apply to building variants: treat the cast and props as random variables — different every time, yet still consistent with the scene and faithful to the campaign's message. ↩