FastH3 V2 · Verify Stage + Condition Origin (T8 EXP)

What it is

The stage attest node proves a sampler ran with the right model, sigmas and source. This one adds the missing half: proving which conditioning call produced the latent that sampler started from.

If you're using the pack's provenance-emitting conditioner instead of the raw native one, you get a typed receipt describing the CLIP, both VAEs, the first frame, the projected Relay plan and the positive conditioning that came out of it. This node takes that receipt plus the conditioned latent and binds them to the completed stage. Same output type as the plain stage attest, so it's a drop-in upgrade wherever you have the receipt to feed it.

Worth being clear about the boundary, because the node description is: this does not certify a HIGH handoff, an accepted parent, a candidate save, or an assembled video. It certifies one stage and its conditioning origin. The rest of the chain has its own gates, and they're separate on purpose.

How it works

It runs the identical attestation check as the base node - comparing the completed stage against the raw MODEL/LoRA, the sampler's actual MODEL, guider, noise, sigmas, source latent, stage context, both Relay plans and the EAV config - and then adds a second binding: the condition receipt's outputs versus the latent that was actually sampled. If the latent you hand the sampler didn't come from the conditioning call the receipt describes, the binding fails.

In practice this closes a real hole. On a split H3 pipeline the conditioning step is where the first frame, the identity reference and the reference videos enter the run. Two graphs can use identical models and identical sigmas and still diverge completely because one of them pointed at a different first frame. The receipt is what makes that visible after the fact instead of in the output.

The typed-identity habit is the pack's whole house style, and it's the same pattern you'll see in the plumbing layer generally: turn an implicit assumption into a value that can travel on a wire, then let a node refuse when the value doesn't line up.

Ports

Everything from the plain stage attest - current_recipe, stage_result, raw_model, stage_model, guider, noise, sigmas, source_latent, stage_context, global_plan, projected_plan, eav_config, segment_index, phase - plus two:

• condition_receipt (the typed receipt from the provenance conditioner)
• conditioned_latent (the latent that call produced)

Outputs are unchanged: stage_attestation, attestation_sha256, report_json. Because the output type matches, you can swap this in anywhere the plain attest node goes; the attestation it emits just carries more provenance.

When to use which

Use the plain stage attest when your conditioning comes from somewhere with no receipt - an older graph, a hand-built conditioning chain, or anything the provenance conditioner didn't produce. Use this one whenever you have the receipt, which in a current FastH3 V2 graph is the normal case. It's strictly more information for the same amount of wiring, and the downstream handoff node is happier with the fuller story.

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

Fully restart ComfyUI, then refresh the page. Nothing to pip-install: the pack keeps requirements.txt empty so installation can't replace ComfyUI's Torch/CUDA stack, and optional EXP bits check their own deps only when used. Required: a recent ComfyUI with native H3 support, H3 weights in models/diffusion_models, Qwen in models/text_encoders, video and audio VAEs in models/vae, and the FastH3 V2 ConvRot INT8 checkpoint if you're running the V2 stages.

Common complaints

The one you'll meet first is a type error on condition_receipt: it wants the pack's typed receipt, and the native Long Video conditioner doesn't emit one. Swap in the provenance-emitting conditioner - same settings otherwise - and re-run the stage. The receipt has to come from the same executed call that produced the latent, so a receipt from an earlier run of the same graph will be rejected. That's the point.

Second: a receipt/latent mismatch after you changed a reference image or the first frame between runs. That's real and it's supposed to fail. Update the conditioning, re-run the stage, attest again.

And as always with this chain - if a downstream node later refuses your candidate with a SHA complaint, come back here and read report_json. It's usually this node telling you exactly which identity drifted, several steps before the failure surfaced.