Submission and demo

The character pipeline — corrected architecture

Status: PLAN OF RECORD · supersedes the video-only framing in 01-SPEC.md §7 Written: 2026-10-29 19:50 PT Why this exists: the user corrected the architecture. We had built a frame judge. The product is a character pipeline. This document is the gap analysis and the plan.

1. What we had wrong

We built the camera-continuity half of continuity and called it continuity.

ChorosContinuity checks the 180° axis and the 30° jump cut — geometric continuity between camera positions. That is real and it is verified. But it says nothing about whether the person in shot 3 is the same person as in shot 1.

The user's framing, verbatim:

We NEED Image guidelines, no?? If we're building this RIGHT, its building images of our characters, building LoRA's, and then applying those LoRA's to LTX Studio for rendering, no?

Yes. That is the pipeline. And it is the same thesis one layer up: Cinema Studio's own words are that AI video distortion "is not a quality problem, it is a memory problem — each new generation is a fresh context." The fix for a memory problem is not a better frame judge. It is identity that persists across shots, which means LoRAs.

2. The pipeline, as it should be

  character sheet          image model            LoRA training          LTX render
  ┌──────────────┐      ┌──────────────┐      ┌──────────────┐      ┌──────────────┐
  │ description  │─────▶│ FLUX.2 /     │─────▶│ Train LoRA   │─────▶│ LTX 2.5 /    │
  │ + refs       │      │ Qwen-Image   │      │ (native)     │      │ 2.3 + LoRA   │
  └──────────────┘      └──────────────┘      └──────────────┘      └──────────────┘
         │                     │                     │                     │
         │                     ▼                     ▼                     ▼
         │              ┌─────────────────────────────────────────────────────┐
         └─────────────▶│  OUR NODES — the judgement layer                    │
                        │  · framing: 14 rules, measured                      │
                        │  · camera continuity: 180° axis, 30° jump cut       │
                        │  · IDENTITY continuity: did the character drift?    │
                        └─────────────────────────────────────────────────────┘

The last row is the differentiator. Everyone can train a LoRA. Nobody in the ComfyUI ecosystem measures whether the identity held — the same way nobody measures whether the framing held. Presets vs judgement, now: "did it drift?" vs "here is the drift, in numbers."

3. What is actually available (verified, not assumed)

3.1 LoRA training is native to ComfyUI core

Verified against docs.comfy.org/built-in-nodes/TrainLoraNode:

TrainLoraNode key inputs: model, latents, positive, batch_size, grad_accumulation_steps, steps, learning_rate, rank, optimizer (AdamW/Adam/SGD/RMSprop), loss_function (MSE/L1/Huber/SmoothL1), seed, training_dtype, lora_dtype, algorithm (LoRA / LoHa / LoKr / OFT), gradient_checkpointing, offloading, existing_lora, bucket_mode, bypass_mode. Outputs: lora (LORA_MODEL), loss_map, steps.

Two traps, both documented:

• steps defaults to 16 — a smoke test, not a run. Character sets want thousands.
• learning_rate defaults to 5e-4, which is SDXL-era. Flux-class bases want ~1e-4 or lower.
• bypass_mode exists for quantized models whose weights cannot be modified directly — relevant to us, because our LTX graphs load int8_convrot and fp8_scaled checkpoints.

Honest caveat: these nodes are marked experimental and shift between releases. The community default for serious character work is still ai-toolkit (MIT, supports FLUX.2 / Qwen-Image / Z-Image Turbo) or diffusion-pipe. We should say that in the README rather than pretend the native path is what professionals use.

3.2 LTX 2.5 vs 2.3 — 2.5 is NOT a superset

Verified by diffing the two official workflow directories in Lightricks/ComfyUI-LTXVideo/example_workflows/:

Why: LTX-2.5 changed the text encoder (Gemma 3 12B → Gemma 4 12B) and the text-projection layer. Every IC-LoRA is trained against a specific base's attention and projection weights, so every community IC-LoRA must be retrained when the base moves. CrossView-Warp is a community artifact (Cseti), trained on 2.3 22B; there is no 2.5 version. The 2.5 IC-LoRAs that exist are Lightricks' own, retrained for 2.5.

Decision (user-approved): ship both, and say why. Three graphs:

1. LTX-2.5 T2V/I2V — best quality, native multishot, Gemma 4.
2. LTX-2.3 + CrossView-Warp — the re-shoot-from-any-angle demo.
3. Wan 2.2 Fun-Control — the Apache-2.0 clean path.

Our nodes judge all three. This demonstrates the interchangeability claim instead of asserting it.

3.3 CrossView-Warp facts (from the model card, not inferred)

• Repo: Cseti/LTX2.3-22B_IC-LoRA-CrossView-Warp_v2, Apache-2.0.
• File: LTX2.3-22B_IC-LoRA-CrossView-Warp_v2_6000.safetensors.
• Node: cseti007/ComfyUI-CrossViewWarp (NumPy + PyTorch only; numba optional 10× speedup).
• Trigger word: crossview. LoRA strength 1.2–1.3.
• Both IC-LoRA guides: latent_downscale_factor = 1, order [warp, source].
• Geometry: MoGe-2 ViT-L metric depth (core ComfyUI node) — matches our stack.
• Trained envelope: azimuth ±45° green, ±90° yellow; elevation +30°/−20° green. Looking up from below is the weak axis — 3.1% of training scenes.
• Documented limitation: distance does not work as expected (dataset problem, promised fix in the next release). A big pull-back under-delivers.
• It steers the viewpoint, it does not reproject it. Large angles are mostly invented.

This is a gift for our entry. The reliability zone our CameraReliabilityZone node already computes — green/yellow/red by azimuth and elevation — is the same envelope the LoRA card documents. We are not inventing a heuristic; we are encoding the adapter's own published training coverage. That is a much stronger claim than we had.

4. The new node: identity continuity

This is the piece that makes the pipeline ours. Working name CharacterContinuity.

Input: two or more rendered frames (or clips) + the character reference set. Output: a per-cut identity verdict with a measured drift value and a correction.

Design constraints, consistent with everything else we have built:

• Pure stdlib, no model, no network. Same as the rest of the pack.
• It must be checkable by hand — a number a human can verify, not a vibe.
• It must fail honestly: if it cannot measure, it says so rather than passing.

Candidate measures, in order of how defensible they are without a vision model:

1. Palette drift — dominant colour histogram distance between the character's region across cuts. Cheap, deterministic, genuinely catches wardrobe/lighting drift.
2. Silhouette/bbox aspect drift — the character's projected proportions across cuts. We already have project_entity_bbox() in scene.py; this reuses it.
3. Anchor-ratio drift — eye height as a fraction of total height (we already use 0.92 × height in anchors()). A change in that ratio means the character's proportions changed, which is exactly what a LoRA failing to hold looks like.

What it must NOT claim: it cannot verify facial identity. That needs a vision model and is out of scope, exactly as the perceptual half of the rulebook is out of scope. The README must say this in the same breath as the claim.

5. Revised build order

Blocked on nothing. The native training nodes mean we do not need an external trainer, a GPU, or a second environment to write these graphs. We still cannot execute them — no GPU, no model weights — and that limitation does not change.

6. What we still cannot claim

Unchanged by this document, and it must stay unchanged in the README:

• No graph has been executed. Zero inferences run. "Structurally validated, neither yet executed" remains the honest sentence, now for four graphs.
• No LoRA has been trained. We can write the graph; we cannot run it.
• Identity continuity is a new, unverified measure. It gets the same treatment as the 14 framing rules: hand-computed fixtures, a mutation gate, and an adversarial pass before it is claimed.
• The native training nodes are experimental and the community default is ai-toolkit. Say so.

Magieva Inc. · 2026