Diagnosing Generation Defects: The Janus-Head Problem and Beyond
When a video model resolves a big head-turn as an in-place spin, it hallucinates a second face — and the fix is structural, not a reroll.
The bug that ships to everyone who copies your prompt
Every director who works in AI video eventually generates a shot that comes back wrong in a way that is hard to describe. Not "bad" in the generic sense — the lighting is fine, the framing is fine, the subject looks like the subject. Something specific and localized is broken: a face that shouldn't be there, an object that reshapes itself mid-shot, text that reads like a fever dream. The instinct is to hit generate again and hope. That instinct is the single biggest waste of budget in this craft, and this lesson exists to replace it with something better.
The flagship example is the Janus-head problem, named for the two-faced Roman god. It is common enough that if you shoot enough reveal beats and big head-turns, you will meet it. Understanding it in full — not just the symptom, but why the model produces it and how to structurally prevent it — teaches the diagnostic method you will apply to every other defect you encounter for the rest of your production career.
Anatomy of the Janus-Head problem
Here is the setup that produces it almost every time. Your start keyframe shows the subject facing directly away from camera — dead-rear, zero face visible. Your end keyframe shows the subject facing fully forward, face completely revealed. This is a dramatically satisfying reveal beat on paper: the character is a mystery, then they turn, and the audience sees them for the first time.
The video model's job is to interpolate a continuous motion between those two states. But it has been given an almost-impossible tracking problem: there is no face visible anywhere in the start frame, so the model has nothing to lock onto and rotate. What frequently happens instead is that the model resolves the 180-degree gap as an in-place head-spin — the head appears to rotate on the neck like a doorknob rather than the character genuinely turning their body — and somewhere in the middle of that spin, it hallucinates a second face. A partial, ghostly face appears on what should be the back of the skull, coexisting for a few frames with the real face before the shot resolves to the correct forward-facing pose.
The defect is not scattered randomly through the clip. It lives entirely inside the transition window — the handful of frames where the model has committed to resolving a rotation it doesn't have enough information to resolve cleanly. This localization is the diagnostic tell: any big head-turn or reveal beat that goes from "no face visible" to "face fully visible" is a structural setup for this exact failure, regardless of which specific prompt words you used.
The three-part fix
All three parts of the fix are cheap on their own — the only thing that costs credits is the regeneration itself, and you should expect to pay for that regardless of which fix you apply. That means there is no excuse for skipping any of the three.
Part one — change the start frame's geometry. Regenerate the start keyframe as a 3/4-rear angle instead of a dead-rear angle, with the face already partially visible in lost profile: a hint of cheekbone, the line of a brow, one eye at the edge of frame. This does two things at once. It gives the model a continuous face anchor to track through the turn instead of nothing at all, and it drops the total rotation the model needs to resolve from roughly 180 degrees down to roughly 110 degrees — a meaningfully smaller and more tractable motion. Crucially, a 3/4-rear angle still reads as "mostly turned away" to the viewer, so the reveal-hook of the shot is intact. You are not giving up the drama; you are giving the model a fighting chance to deliver it cleanly.
Part two — rewrite the motion prompt to be camera-driven, not subject-driven. Subject-driven language ("he turns to face the camera") invites the model to treat the head as the thing doing the rotating, which is exactly the behavior that produces the spin-and-hallucinate failure. Camera-driven language redirects the motion onto the camera instead: direct, explicit instructions like "the camera moves, the subject does not turn; his head never spins, never turns from back to front; single continuous head." That phrasing is not decorative — it is telling the model, in terms it can act on, which entity is allowed to move and which is not.
Part three — add negative prompts that name the defect directly. Do not rely on positive language alone to prevent something you have already seen the model do. Add explicit negative prompts naming the failure: "a second face, a second head, two-headed figure, a face on the back of the head, duplicate/morphing face, head spinning 180 degrees." Naming the specific defect you're guarding against is more effective than generic negative-prompt boilerplate, because you are working from a known failure mode, not guessing at what might go wrong.
The publishing discipline
There is a rule specific to "copy this prompt" content that doesn't apply to work you never publish: if you ship a piece built around a specific reference-and-prompt pairing, and you later discover and fix a defect in that same prompt structure during a subsequent production, you are obligated to update the published prompt to the working version. The entire premise of a copy-this-prompt reel is that a viewer takes your exact prompt and reproduces something close to your result. A defect-prone prompt left live on a published piece is not a historical artifact — it is an active bug that every future viewer who trusts your content will reproduce. Treat the correction with the same seriousness you'd treat a code fix that needs to ship to every user of a library, because functionally, that's what it is.
General diagnosis doctrine: defects are data
The Janus-head problem is the flagship example precisely because it teaches a transferable method. The wrong mental model is "generation is stochastic, so a bad take is bad luck — try again." The right mental model is that most defects recur under specific, identifiable structural conditions, and each condition has a specific structural fix — not just a prayer and a fresh seed.
The structural conditions worth watching for as a working director: extreme single-generation angle changes (anything close to a full rotation in one shot), ambiguous reference-role assignment (the model isn't sure which reference governs which element), over-cramped shotlists (too many distinct beats crammed into one generation, starving each beat of the frames it needs to resolve cleanly), text-in-video requests, and exceeding a model's character-count limits on the prompt itself (which silently truncates or garbles instruction fidelity). Every one of these has a specific, learnable fix. None of them are solved by rerolling harder.
Two more defect classes
Two more failure modes are common enough to name explicitly, both covered in the comparison matrix below alongside the Janus-head problem.
Prop distortion from an image-composition reference. When you use an --image-style composition reference to lock a pose or a scene layout, held props — a weapon, a tool, any object gripped in a hand — can visibly warp or reshape across the generation: extra barrels, melting stock, geometry that reforms frame to frame. Image-composition references are strong at locking broad pose and framing; they are unreliable at holding the fine geometry of small held objects. The fix is structural: describe the object's shape, material, and grip in clean prompt-only language, and use image references sparingly for that specific element rather than leaning on them for everything at once.
Garbled or reversed on-screen text. Any text, numbers, or labels rendered inside a generated shot — a sign, a readout, a logo — are unreliable regardless of how carefully you word the prompt. This is a hard model limitation, not a prompting problem, and no amount of phrasing will make it consistently reliable. The fix is to stop asking the model to solve it: route all in-scene text through a post-production overlay pass instead, where you have full typographic control.
Build it: a defect diagnosis rules engine
You're going to build the tool a working director actually reaches for: a small rules engine that takes a described symptom and returns the correct fix plan, so the diagnosis step is fast and repeatable instead of reinvented from memory every time.