DiffusionGemma Advertisement Director Packet Repair
A JSON Paramedic That Only Acts When the Transport Actually Broke
- final_json
- repair_report_json
- status
- ready
DiffusionGemmaAdvertisementDirectorPacketRepair is the surgical fixer in the advertisement stack, and the discipline in its design is what makes it worth reading about. In this pack, the DiffusionGemma Director authors the H3 prompt as a JSON packet. Normally that packet flows through untouched - the node uses the host-final packet as-is and preserves all its grounding, runtime, and cache evidence. But sometimes an LLM produces JSON that doesn't quite parse, and in that narrow case this node steps in to repair the transport damage. The key word is narrow: it only intervenes when the host explicitly reports a JSON parse failure, plain salvage succeeded, and no real template fallback occurred. Otherwise it keeps its hands off.
The repair scope is deliberately bounded, straight from the README: it fixes invalid in-string backslashes and completes governed Subject-row delimiters using the SHA-locked reference contract. That's basically it. Duplicate keys, non-finite values, malformed Unicode, excess repairs, extra prose, metadata disagreement, and reference-authority changes all fail closed. The H3 validator downstream stays the final authority on prompt structure. This is the opposite of an "LLM, please fix my JSON" free-for-all node - it's a paramedic with a strict protocol, because in a governed ad workflow a rogue repair could smuggle in a product claim nobody approved.
Its inputs are the full set of Director evidence you'd expect it to cross-check: director_final_json, director_raw_response, director_metadata_json, grounding_status, grounding_report_json, and reference_contract_json. Outputs are final_json (the packet to pass to the splitter/gate), repair_report_json (what it did, if anything), and the status/ready pair. If no repair was needed, you get the host packet back and repair_report_json should show a no-op - which is the outcome you want, because an intact packet is always preferable to a repaired one.
Why does an ad stack need this at all? Because DiffusionGemma is a real local LLM and real LLMs occasionally emit a stray unescaped backslash, and in a long 99-node render the difference between a graceful bounded repair and a hard failure is whether your queue finishes. But it exists to be mostly invisible.
The main thing beginners get wrong is expecting this to be a general prompt-fixer. It is not. If your prompt is conceptually wrong - wrong subject count, bad shots, ungrounded claims - this node will not save you, and neither will it pretend to; those failures belong to the Generation Gate and validator, which block properly. Also note: it consumes the Director's diagnostic outputs, so if you disconnect those strings to "simplify" the graph, the node can't verify its cross-checks and the fail-closed posture collapses. Wire it the way the example workflow does.
Install is pack-wide: ComfyUI Manager search "DiffusionGemma Prompt Builder", or git clone https://github.com/exportAnything/ComfyUI-DiffusionGemmaPromptBuilder into custom_nodes and restart. Realistically you'll only care about this node if you're running the Director + H3 ad pipeline at scale and occasionally see JSON transport hiccups; on short test runs it sits idle, which is exactly what a well-built paramedic should do.
Inputs (6)
| Name | Type | Default | Description |
|---|---|---|---|
| director_final_json | STRING | — | |
| director_raw_response | STRING | — | |
| director_metadata_json | STRING | — | |
| grounding_status | STRING | — | |
| grounding_report_json | STRING | — | |
| reference_contract_json | STRING | — |
Outputs (4)
| Name | Type | Description |
|---|---|---|
| final_json | STRING | — |
| repair_report_json | STRING | — |
| status | STRING | — |
| ready | BOOLEAN | — |