FastH3 V2 · Verify LOW→Upscale→HIGH Origin (T8 EXP)

What it is

Every split pipeline has one joint that can ruin everything: the handoff. In FastH3 V2 the chain is LOW 0:4 → learned 3D lift → reconcile → prefix → HIGH 4:8, and if any link in that sequence was fed the wrong tensor, the render still completes. It just isn't the render you designed.

This node is the read-only proof that the handoff was real. It takes the completed LOW result, the completed HIGH result, both stage attestations, both condition receipts, the upscale receipt and its latent, plus the HIGH-side template, positive conditioning and source latent - and checks that they describe one continuous chain. What it emits is a typed statement: this HIGH pass started from a latent that came from this upscale, which ran on this LOW pass.

The scope note matters: it does not accept a segment. It doesn't save, doesn't write, doesn't compose. It proves the shape of the graph and hands you handoff_attestation for the nodes downstream that need it.

How it works

The verification is a chain of identities rather than a vibe check. The LOW stage attestation says a particular LOW stage ran with particular inputs. The upscale receipt says a particular latent went in and another came out. The HIGH stage attestation says the HIGH sampler started from a latent whose identity matches the upscaled one - and this node also compares the HIGH template and the HIGH positive conditioning, which is where a handoff most often goes subtly wrong: right latent, wrong prompt context, and the second half drifts.

The reason it looks like it has an absurd number of ports is that each of those ports is one link in that chain. Nothing here is optional in spirit, even though a couple are optional in the schema.

What you actually wire

• current_recipe - the editable-recipe fingerprint from CurrentRecipeEXPT8. It's the "what I intended" side of the comparison.
• low_result, high_result - both completed T8_STAGE_RESULTs.
• low_attestation, high_attestation - one per stage, from the stage attestation nodes.
• low_condition_receipt, high_condition_receipt - from the provenance-emitting conditioner, one per stage.
• upscale_receipt, upscaled_latent, upscale_report_json - all three from the learned 3D upscale node.
• high_template, high_positive, high_source_latent - the HIGH stage's actual conditioning and starting latent.
• segment_index - 0 or 1.
• contexts (optional) - the continuation contexts when this segment is a continuation.

Outputs: handoff_attestation (T8_FAST_H3_V2_CURRENT_HANDOFF), handoff_sha256, report_json. The attestation goes into the job-binding node; the SHA goes into anything that wants a receipt.

Where it fits in the pipeline

Order matters and it's easy to get wrong: stage attestations after each sampler, upscale provenance at the lift, this node after the HIGH stage completes and before the job bind. If you put it before the HIGH pass, it has nothing to compare and will refuse.

This is also where an accidental "close enough" graph dies. Re-run the HIGH stage but forget to re-run the upscale, and the two no longer match. That's a refusal, and it should be - the whole point of a distilled 8-step split is that a stage is cheap to re-run and expensive to leave inconsistent. Compare that to a hidden-loop mega-node, where the same mistake would just produce slightly-off video and no complaint at all.

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 completely, restart, refresh. There's no pip step by design - the pack keeps requirements.txt empty so installation can't replace ComfyUI's Torch/CUDA stack - and optional EXP features check their own dependencies only when invoked. Prerequisites are a recent ComfyUI with native H3 support, H3 weights in models/diffusion_models, Qwen in models/text_encoders, both VAEs in models/vae, the FastH3 V2 ConvRot INT8 checkpoint and the learned 3D upscaler.

When it says no

Read report_json before you change anything. It compares quantities pair by pair, and in the vast majority of cases the mismatch is nameable: a stale receipt from a previous run, a HIGH latent that came from a different upscale call, or a high_positive built from a conditioning pass that ran before you changed the first frame. Fix the upstream thing and re-run - don't hunt for a bypass. These nodes are not configurable into agreeing with you, which is the feature.

One genuinely common cause: segment_index left at 0 in a continuation graph, or contexts left unwired when the segment is segment 1. Both produce a refusal that reads like a model problem and is actually a wiring problem.