DiffusionGemma Advertisement Master Contract

DiffusionGemmaAdvertisementMasterContract is the notary of the advertisement stack - the node where the three sub-contracts you've built so far (campaign, references, soundtrack) get fused into one validated project contract, cross-checked against immutable hashes, and stamped with a campaign id that everything downstream has to agree on. If the campaign contract is where you type the ad and the reference asset prep is where you hash the images, this is where the whole thing becomes a single document with one identity.

Look at its inputs and you'll see it's a meeting point rather than an author: campaign_contract_json, reference_contract_json, soundtrack_contract_json, and project_manifest_json come in from the earlier nodes, joined by the three reference hashes (performer_hero_sha256, performer_contact_sheet_sha256, product_package_sha256 - derived from the images, never typed by hand) and master_audio_sha256 from the locked soundtrack. The node verifies those hashes match what the reference contract and soundtrack contract claim, checks the project manifest's audio hash against the master audio hash, and validates the requested aspect, lane ceiling, and deliverables against its schema. It also takes native_shot_count (the storyboard's shot count, 8 by default) and boundary_mode, locked to relay_continuity because advertisement v1 only supports the retained-tail relay seam.

Out the other side: advertisement_contract_json - the master contract every planner, assembler, finisher, and QA gate reads - plus campaign_id (a deterministic id that later manifests must match to be accepted), generation_lane_count, reference_manifest (the typed Picture-role lines, now including a Picture 4 relay row), and the status/ready pair.

A subtlety worth knowing: this is where the code corrected a classic off-by-one bug that the changelog calls out - mixing up "native H3 shot blocks" with "number of generation invocations." The native_shot_count you enter here is the storyboard's camera cuts (multiple of which can live inside one H3 clip), not the number of H3 calls. The lane count is computed separately by the planner from duration and the 15-second lane ceiling. If you've ever assumed shot count equals generation count in a multi-lane video workflow, that's exactly the trap this contract exists to disambiguate.

The failure mode beginners actually hit is hash mismatches. If you re-run reference asset prep and get a new image hash, or replace the soundtrack, but the old master contract is still wired in, this node will fail closed rather than assemble under stale authority. That's correct behavior - you should regenerate the master contract after any image or audio change - but it can look like a confusing error until you realize the hash chain is doing its job. When in doubt, trace the hashes back to the source nodes and rebuild.

Install is pack-wide: ComfyUI Manager search "DiffusionGemma Prompt Builder", or git clone https://github.com/exportAnything/ComfyUI-DiffusionGemmaPromptBuilder into custom_nodes and restart. The ad workflow around this node wants ComfyUI 0.33.1+ and the H3/Music 3 model downloads; this node is pure JSON validation and cross-checking, costing no GPU. Get the contract right here and the finishing chain below it has a single source of truth to obey.