H3 Multi-Face · Source-Bound Candidate Audit (T8 EXP)

What it is

A gate that sits between one character's sampled repair stage and the parity stitch / sequential composite that follows. It takes the sampled stage_result, the character's face_plan, the source_frames, the parent_frames and the av_latent, and verifies that this candidate belongs to the same job window, against an unchanged parent, with source AV that hasn't shifted underneath it.

Outputs: candidate_av and report_json. It's an output node, so it can legitimately end a branch.

Why a whole node for this? Because in a multi-character graph you're running several near-identical stages that differ only in window and plan. The class of bug you get there is not "it crashed" - it's "character B's repair got composited into character A's slot," or "the parent frames were regenerated between stages and nobody noticed." Both are visually subtle enough to survive review until someone points at it.

What it checks

• The stage result is a real sampler-produced result, and the stage context inside the receipt is bound with this character's face plan - it verifies against the plan contract rather than trusting a label.
• The source_frames and parent_frames you're handing it now are the ones the stage was bound with, and the AV latent matches too.
• The recipe binding checks out, so a candidate from a different route in the pack can't be smuggled in.

The honest caveat

The node's own wording is worth quoting because it defines what you're buying: unknown sampler completion is not portable or automatically accepted.

Meaning - if you swap in a custom or third-party sampler, the stage may well run, but the pack won't pretend to certify its completion pattern. And nothing here auto-accepts the repair. Acceptance in this workflow family is manual by design; the audit is there to make sure the thing you're about to review is the thing you asked for.

Inputs and outputs

Inputs: stage_result (a T8_STAGE_RESULT from the pack's stage sampler), face_plan, source_frames, parent_frames, av_latent. No knobs.

Outputs: candidate_av, report_json.

face plan → MultiFace Stage Bind (per character) → sampler → Stage Sampler
                 → MultiFace Stage Audit → Parity Stitch → sequential Composite

Install

cd ComfyUI/custom_nodes
git clone https://github.com/T8mars/comfyui-minimax-h3-audio-T8.git minimax-h3-audio-T8

Manager: search MiniMax H3 Audio T8, install, then quit ComfyUI completely and restart, then refresh the page. If the node is absent while GitHub has it, clone - the ComfyUI registry and this repo's GitHub releases are published independently.

Models: the standard H3 set - transformer in models/diffusion_models, Qwen3-VL text encoder in models/text_encoders, video and audio VAEs in models/vae - plus whatever face detection/segmentation models the workflow's window planning step names. The repo contains no weights, and requirements.txt deliberately declares no packages so installation can't replace ComfyUI's torch/CUDA stack.

Use the shipped graphs (examples/workflows/56-face-refine-split, plus the frozen multi-face source and isolated-delivery docs). The multi-face route has two- and three-character variants and they are not one recipe with a count parameter.

Common issues

"Belongs to another job window / parent changed." You regenerated the parent, or you're auditing character A's candidate against character B's plan. Rebind the stage and re-run it rather than forcing the audit through.

It refuses a candidate that you know is fine. Verify you're passing the parent frames the stage was bound with, not a re-render that happens to look identical.

The repair is accepted but the composite looks wrong at the boundary. That's stitch/composite territory - this node is about provenance, not blending. Keep the acceptance step manual and look at the join frame by frame; the pack's own docs admit seam behaviour is genuinely hard.

Red nodes / missing. Update ComfyUI core, the frontend and Manager together and restart fully.