H3 Continuum Conditioning Bridge V3.5

The H3 Continuum Sampler is opinionated about how it samples. It builds its own chunked continuation, its own AV latent pairing, its own noise and Audio Lock. That's great when you want the one-button long-form path. It's a wall when you want to drive the actual diffusion yourself - say, with ComfyUI Core's BasicGuider and an external sampler, or after processing the latents with a third-party latent upscaler like LBH.

H3 Continuum Conditioning Bridge V3.5 is the door through that wall. It's the Advanced connection point for external sampling: it takes Continuum's prepared state and hands you back ready-to-use MODEL and CONDITIONING objects, one pair per physical group, so the external workflow takes over from there.

What it does - and what it deliberately doesn't

The bridge adapts the captured refine_context to your externally processed physical-group video latents and returns aligned group_models and conditioning lists plus an updated assembly plan at the target geometry. Then it steps aside. It does not create AV LATENT pairs, noise, SIGMAS, Audio Lock, or any sampling policy - the README is explicit that those remain the external workflow's responsibility. Think of it as a translator that converts Continuum's internal state into standard ComfyUI objects, not a sampler.

The README's wiring for the common case:

H3 Continuum Sampler V3.5.video_latents
  -> external H3 latent processor (for example LBH)
  -> H3 Continuum Conditioning Bridge V3.5
  -> Core BasicGuider + external sampler
  -> Core Video / Audio VAE Decode
  -> H3 Continuum Assemble + Seam V3.5

Inputs

Required: model, clip, video_latents (the externally processed ones), assembly_plan, and refine_context - all straight from the sampler. The optional video_vae matters for one thing: when it's connected, First/Last keyframes are re-encoded at the target geometry instead of using the conditioning adapter's documented latent-resize fallback. If you're upscaling and you have the VAE, connect it.

Outputs

• group_models - a list of MODEL, length equals the physical-group count.
• conditioning - a list of complete CONDITIONING objects, same length, each entry complete (never flattened into the physical-group list). This matters if you're scripting - you can't just assume entry N is a slice of one big conditioning.
• updated_assembly_plan - the plan re-mapped to the target geometry; feed this to Assemble + Seam later.
• status - a string report of groups, prompt policy, and conditioning source per physical group.

One thing to understand about the "physical group" framing: Continuum splits a run into logical chunks, but the final two 5-second FL2VA chunks can merge into one physical sampling unit (Terminal Merge). The bridge works at that physical-group level, which is why the outputs are lists and why you shouldn't assume one element per chunk.

Installing it

Same pack as the rest of H3 Continuum - ComfyUI Manager, search "H3 Continuum", or:

cd ComfyUI/custom_nodes
git clone https://github.com/ukr8b3g-cmyk/ComfyUI-H3-Continuum.git

Restart ComfyUI after installing. No extra pip dependencies. The bundled example workflow also uses external nodes (LBH latent upscaling, AV latent concat, loaders) - install or replace those per your environment.

The gotchas

This is an Advanced node and it behaves like one: if your external workflow never builds noise or SIGMAS, nothing will sample. The example keeps Core's BasicScheduler for a reason. And note LBH only changes latent geometry - there's no Continuum denoise control here, so how strongly the resized latent gets regenerated is decided entirely by the external scheduler's SIGMAS. Larger LBH scales are faster per pixel but memory and decode costs grow with the target canvas. Start at 1.5x, not 2x, unless you have headroom to burn.