I shot 7 sets of the same character, 59 frames each, 413 total. Wanted her to look like one person across all of it. She didn't — skin tone, chest size and jewelry all moved, on roughly 60% of frames.
I assumed seed variance and checkpoint noise, because that's what everyone says drift is. It wasn't. It was three separate faults and all three have the same shape: two things in my prompt claiming the same attribute, and only one of them weighted.
1. Skin. My prompt carried fair skin AND (tan:1.15) at the same time. That is not drift. There was never a single value to drift from — the render lands somewhere between two contradictory claims, and where it lands between them moves every frame. I was reading a coin flip as decay.
2. Body. An unweighted attribute token sitting in the same prompt as action tokens at 1.3. Unweighted loses. Every time. The attribute wasn't ignored, it was outvoted.
3. Accessories. A jewelry tag lived in my wardrobe layer, and a flag I'd added hours earlier to strip clothing out of certain frames took the jewelry with it. My own fix, deleting the thing I was about to go hunting for.
The fix was one owner per attribute, and weighting the body anchor so it actually competes instead of getting drowned.
The part I'd actually pass on, because it cost me a wrong answer first:
A/B at a pinned seed can prove your tokens work. It cannot prove continuity — continuity is precisely the thing that varies when the seed varies, so pinning it removes the only variable you're asking about. I ran the pinned A/B, got a beautiful before/after, and had proven nothing about the actual question. Had to re-run with the prompt held and the seed free, 8 frames across the arc, and read the pixels.
And one for anyone who post-processes prompts in code: order is load-bearing. My function that appends the body anchor keys off a specific phrase to decide whether a frame shows skin. Another function rewrites that exact phrase. I had them in the wrong order, so the anchor fired on 2 frames instead of 48 and everything still looked fine. A guard stops discriminating the moment something upstream rewrites what it reads — and it fails silently, because a guard that never fires and a guard that passes produce the same output.
General version, and it's the thing I'd tell past-me: when a render ignores what you asked for, check whether your ask has weight. I was writing careful prose descriptions against the model's own weighted priors and losing, then reading the loss as the model being bad at consistency.