H3 Source-Profiled Renderer

There is a difference between a prompt that's shaped like an H3 prompt and a prompt that satisfies the official H3 prompt-writing guide. Most prompt tooling can't tell you which one you have. H3 Source-Profiled Renderer takes a typed plan, renders it into the documented grammar, then re-reads its own output and checks it - against a specific, pinned revision of MiniMax's guide, by digest.

One input. Three outputs. It's the strictest node in the pack's prompt path, and it's the one to reach for when you want the prompt to be checkable rather than merely plausible.

How the rendering works

The required plan input is H3_CONTEXT_PLAN - typically from H3 Context Plan, or the accepted plan out of the Constrained Semantic Planning chain. Anything that isn't an exact plan object is rejected (invalid_plan), which matters because this node will not accept a loose string and pretend.

From there it picks the renderer for the plan's profile: the Base document, or the Full-Reference document. Then - and this is the actual mechanism of the node - it validates the exact rendered output: re-parse, lint, and a fidelity audit that compares the document back against the plan that produced it. The guide source itself is bound by revision and SHA-256 digest, so a renderer that quietly followed a different guide revision would be reported as drifted rather than accepted.

If any of that fails, the node raises source_profiled_render_failed and produces nothing. Fail-closed, no half-rendered prompt. Given that the alternative is discovering the problem after a two-minute video generation, that's the trade I'd take.

The outputs and where they land

• prompt (H3_PROMPT_STRING) - the finished text. Into H3 Native MiniMax H3 Adapter, which writes it onto the native H3 generation nodes.
• profiled_result (H3_SOURCE_PROFILED_PROMPT) - the profiled result object, carrying the source binding and validity. Anything that wants provenance reads this, not the string.
• prompt_document (H3_PROMPT_DOCUMENT) - the structured document. This is what H3 Context Validator requires as its prompt_document input, and H3 Local Reconstruction wants it too.

Compare with H3 Context Compiler, the pack's other renderer: same plan in, but it emits the prompt plus a report, and it's the lighter route used in the README's minimum pipeline. If you want the prompt_document for the Validator, this is your node.

Plan -> Source-Profiled Renderer -> Validator(plan, prompt_document)
                                 -> Native H3 Adapter -> MiniMaxH3ImageToVideo

Guide readiness is a separate verdict

Worth internalising, because the pack's docs make a point of it: a prompt can be valid and still Incomplete. Structural validity proves the document has the right shape; guide readiness asks whether the typed plan actually owns the semantics the official guide expects - mode, audio obligations, and so on. Readiness is computed from the plan, never from the prose and never from a flag you set. And neither verdict says anything about whether the video will look good. Validation grades paperwork.

One limitation to know before you plan around the Full-Reference path: the pack's README states that H3 Full Reference Timeline Producer cannot be queued in this release (it reports perception_profile_unavailable whether or not you connect a visual result). The recommendation there is to write full-reference prompts with the Plan and Compiler nodes instead. This renderer will happily render a full-reference plan, but the timeline route that would produce one from reference media isn't a road you can drive yet.

Install it

The pack isn't in the Comfy Registry yet, per its README, so:

cd ComfyUI/custom_nodes
git clone https://github.com/rookiestar28/ComfyUI-MiniMaxH3-Studio.git

Restart ComfyUI; the node appears under Add Node → h3_context → compiler. There are no Python dependencies and the install downloads nothing - the guide binding is a compile-time pin in the code, not a file it fetches at runtime, so this works offline. Same repository author as the ComfyUI-Doctor pack, and the style is recognisable: fixed revision, fixed digest, refusal instead of clever fallback.

If you hit source_profiled_render_failed, work upstream - the render is failing because the plan or the document didn't hold up, not because the node is unhappy with your prose. The bundled workflows/m13_10_local_reconstruction.json shows the full working chain, including which socket of the renderer feeds the Validator.