DiffusionGemma Advertisement Planning Defaults

DiffusionGemmaAdvertisementPlanningDefaults is a mercy node. In the middle of the DiffusionGemma Prompt Builder's advertisement stack sits a planner that wants two chunks of JSON - per-shot product-presence metadata and per-lane state - and hand-authoring that JSON is exactly the kind of chore that makes people bounce off "governed" workflows. This node generates production-safe defaults for both, so a campaign can run without you ever opening a schema file. If you're the kind of person who wants to hand-author those payloads, its outputs are plain strings you can override downstream anyway.

Mechanically it's almost boring, in a good way. You feed it advertisement_contract_json (the campaign contract that earlier nodes in the stack produce), plus two human inputs: product_use, a prose description of how the performer handles the product - the default is a sensible "carries, opens, presents, and enjoys it while keeping the package recognizable" - and seam_style, currently locked to "Campaign default" since advertisement v1 only supports one seam contract. Out come shot_metadata_json and lane_states_json with typed defaults the planner accepts, a planning_brief STRING explaining what was generated, and the pack's universal status / ready pair so the gate-keeping downstream can confirm the payloads parsed.

Why does this exist instead of just hardcoding defaults inside the planner? Because the product-presence story is genuinely per-campaign. The whole advertisement stack is built around a hard rule: Picture 3 is the product authority, and every H3 lane has to keep the product visible and recognizable without ever letting product shots steal performer identity. product_use is how you tell that system what the product is doing in your particular ad - a beauty product gets a different default than a beverage - and the node turns your sentence into structured per-shot guidance the planner can enforce lane by lane. That's the difference between a reusable node and a one-off: the prose is yours, the schema is theirs.

The two fields a beginner actually touches are product_use (edit it to match your product) and advertisement_contract_json (wire it from the contract node; don't retype it). Leave seam_style alone - one choice today means there's nothing to choose.

The real gotcha with this entire stack, and therefore with this node, is contract integrity. Every downstream node verifies that the JSON it received belongs to the same campaign revision by checking campaign id and SHA-256 hashes. If you edit advertisement_contract_json by hand and get it out of sync with the root contract, the planner will fail closed with a mismatch error rather than limp along. Don't fight that - the hash-locking is the entire point of a governed workflow. Change the root contract and let the chain regenerate.

Install is pack-wide and trivial by ComfyUI standards: Manager, search "DiffusionGemma Prompt Builder", or clone the repo into custom_nodes. The heavier reality is the graph around it: this is the MiniMax-H3 Ref2VA advertising workflow, which wants ComfyUI 0.33.1+, the H3 and Music 3 model files, and ideally 24+ GB of VRAM to run end to end. This node itself is pure JSON generation - it won't cost you a watt of GPU.