DiffusionGemma Advertisement Adaptation Status

DiffusionGemmaAdvertisementAdaptationStatus is a node whose entire job is to say "no, that wasn't rendered." When your campaign contract requests 1:1 and 16:9 adaptations alongside the primary 9:16 master, this node reports the status of every requested aspect adaptation as planned, inapplicable, or impossible - and its description is admirably direct about the limitation: it cannot emit a rendered status, because it receives no adapted pixels. In a world of demo videos that overclaim, this is the node that keeps the books honest.

Its single input is advertisement_contract_json - the master contract that records what adaptations were requested. That's it. It has no image inputs at all, which is the entire design point. It reads the contract, checks each requested adaptation against what the finishing pipeline can actually produce, and reports. On the output side you get adaptation_status_json (the structured report, schema-versioned and campaign-bound), requested_adaptation_count, all_requested_rendered - a BOOLEAN that in the shipped v1 workflow will be false whenever 1:1 or 16:9 adaptations are requested, because a semantic reframe renderer isn't connected - and the usual status/ready pair.

Why does this exist instead of the pipeline just not mentioning adaptations? Because the pack's designers decided that silently ignoring a deliverable is a failure mode worth engineering against. A client says "we need 16:9 for YouTube," you run the ad, and the workflow happily reports completion - that's how promises get broken. This node makes the gap visible: the plan records the 16:9 request, and Adaptation Status states plainly that it remains unrendered until a semantic reframe renderer is connected. The cutdown renderer downstream also cross-checks its manifest against this report, so a delivery manifest can't claim adaptations were done when the status says otherwise.

In the actual v1 workflow, the delivered formats are the 9:16 master plus real 15-second and 6-second cutdowns (those are temporal cuts from the master, and they genuinely render). The 1:1 and 16:9 requests are the status-only ones. So when you look at the output and see all_requested_rendered: false with a status like "1:1 and 16:9 remain planned/unrendered," that is not a bug - it's the node doing exactly what it was built to do, and it's the correct, honest state of the governed v1 system.

The beginner trap would be trying to force this node to report rendered status by connecting images to it. There are no image inputs - you can't, and the error you'd get from trying to bend it that way is the point. If you need real 1:1 or 16:9 masters, that's a semantic reframe pass you add outside this v1 stack; this node's role is to keep the paperwork truthful in the meantime.

Install is pack-wide: ComfyUI Manager search "DiffusionGemma Prompt Builder", or git clone https://github.com/exportAnything/ComfyUI-DiffusionGemmaPromptBuilder into custom_nodes and restart. It's a pure JSON/reporting node - zero GPU, zero models. It belongs in the delivery bookkeeping section of the workflow, right before the cutdown renderer and the Media QA gate, which are the nodes that actually produce and judge real deliverables.