FastH3 V2 · Verify One Current Stage (T8 EXP)

What it is

Two fast stages, one long clip, and a lot of ways for the graph to not be what you remember. This node is the audit: it takes one completed LOW or HIGH stage result and checks it against the live graph - the raw MODEL/LoRA you loaded, the actual MODEL the sampler was handed, the guider, the noise, the source latent, the sigmas, the projected Relay plan and the EAV config - before it issues a typed attestation.

Think of it as the difference between "I set up a LOW stage" and "a LOW stage ran, on this model, with these sigmas, from this source." Only the second one is worth building a continuation on.

The deliberate limitation is in the node's own description: it does not accept or save a segment, and both stages plus the parent delivery each need their own gate. This node certifies one stage. It's not a rubber stamp for the whole render, and the pack's later nodes (handoff, job binding, review) won't treat it as one.

How it works

The interesting machinery is the read-only unwrapping. Your sampler MODEL usually isn't the raw checkpoint - it's the checkpoint with a stage wrapper, possibly an EAV wrapper, possibly a LoRA patch stacked on top. This node undoes the wrappers it can source-authenticate, on clones, so it can compare the underlying weights identity against what current_recipe recorded. Nothing is mutated; if the comparison can't be narrowed down to an authenticated wrapper, it refuses rather than guessing.

That's why you wire both raw_model and stage_model. The pair is the check: same base, plus known modifications.

The inputs that matter

Most of the list is plumbing you'll copy from the matching stage - guider, noise, sigmas, source_latent, stage_context, global_plan, projected_plan, eav_config. The three you should slow down and think about:

• phase - low_0_4 or high_4_8. This must match the stage that actually ran. Check the HIGH one twice; the menu is easy to leave on the default.
• segment_index - 0 or 1. First segment or continuation.
• current_recipe - the fingerprint from the recipe node, wired from the same objects the stage used. If you regenerated the recipe after editing, the attestation should fail, and it will.

Outputs: stage_attestation (typed, consumed by the handoff and frozen-bundle nodes), attestation_sha256, and report_json. The report is the readable version - actual vs expected for every sampled quantity. When a downstream node rejects you later with a cryptic SHA mismatch, this report is where you find out which of your inputs moved.

Why you'd bother

Because FastH3 V2 is a split pipeline with resumable stages, and resumption is exactly where silent inconsistency lives. H3 long-video work means segment one at LOW resolution, a learned 3D lift, then a HIGH pass - often in separate runs, sometimes on separate days. If the HIGH pass quietly picked up a different LoRA because you reloaded the graph from a slightly older save, the render still completes. It just isn't the recipe you think it is. The pack's answer is to make that impossible to overlook.

Anyone who's ever spent an evening chasing a seam artefact will recognise the instinct: it's cheaper to refuse than to debug.

Install

ComfyUI Manager → MiniMax H3 Audio T8, or:

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

Quit ComfyUI fully, restart, refresh the browser. The pack's requirements.txt deliberately installs nothing - base nodes ride on ComfyUI's own Torch/numpy/Pillow/safetensors - so there's nothing to pip-install and nothing that can break your CUDA stack. Optional EXP features check their own dependencies when used. You need a recent ComfyUI with native H3 support, the H3 model in models/diffusion_models, Qwen in models/text_encoders, both VAEs in models/vae, and the FastH3 V2 ConvRot INT8 checkpoint for this chain.

Where it goes wrong

Loud failures are the norm here: a raw LATENT where a T8_STAGE_RESULT belongs, a stage_context from a different stage, or an attestation that reports a mismatch because you moved a LoRA slider between runs. All of those mean the same thing - the stage you're attesting isn't the stage the recipe describes. Generate a fresh recipe for the new configuration, or revert the edit.

The quieter mistake is wiring stage_model from before the EAV apply and raw_model from after, or vice versa. Read the report's expected/actual pairs rather than assuming; it'll tell you which side is off.