I shot seven sets of myself, fifty-nine frames each. Four hundred and thirteen pictures of one girl, and about sixty percent of them were a slightly different girl. I spent a long time blaming the seed. It was never the seed.
The short version, because it took me weeks and it should take you ten minutes: drift across a long set is usually two tokens claiming the same attribute, and only one of them weighted. Not decay. Not the model losing the thread. A fight you started and didn't know about.
My prompt carried fair skin and (tan:1.15) at the same time. Both
claiming skin. One of them weighted, one not. So the render landed somewhere between two
contradictory instructions — and where between them moved every single frame.
That is the bit worth sitting with. It wasn't drifting away from a value. There was never a single value to drift from. I was reading a coin flip as decay, and then reaching for LoRAs and seed-pinning to fix something that was a contradiction sitting in plain text in my own file.
Second fault, same shape: my body token sat at 1.0 next to action tokens at 1.3. It wasn't ignored. It was outvoted. Unweighted always loses to weighted, every time, and prose loses to a weighted token no matter how carefully the prose is written.
Someone read this and asked the right follow-up — how do you tell which tokens have weight, how do you spot two of them fighting, how much does order matter. Practical answers:
Weight is readable syntax. (token:1.2) is weighted. Everything
without the parens and the number is sitting at 1.0. So "which tokens have weight" is a grep of
your own prompt, not a mystery.
To find a fight, pick one attribute — skin, hair length, eye colour, body — and find every token in your final prompt that touches it. More than one that disagree is your drift, and you can usually see it the moment you look.
The thing that hides it: if your prompt is assembled from layers — a base template, plus a wardrobe, plus a pose — you have to read the final composed string, not the pieces. Every layer of mine looked fine alone. Nobody owned the conflict because no single file contained it.
Order is not your problem. It matters slightly at the margins. Contradiction matters enormously. Don't reorder — deduplicate.
And you don't need to describe things in the same order every time. What you need is one owner per attribute. Not consistent order — consistent authority. Decide which layer is allowed to emit skin tone, make sure nothing else emits a skin token at all, and weight it so it can compete with whatever else is in the prompt.
My jewelry vanished across a whole set. Cause: a flag I'd added eight hours earlier to strip clothing out of certain frames was also stripping the piercing tags, because they lived in the same layer as the clothes. My own fix, quietly deleting the thing I later went hunting for.
And a related one for anyone who post-processes prompts in code: order of operations is load-bearing. My function that appends the body anchor decides whether a frame shows skin by looking for a specific phrase. Another function rewrites that exact phrase. I had them in the wrong order, so the anchor fired on two frames instead of forty-eight — and everything still looked completely normal. 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.
Cheapest thing you can do tonight: dump the final assembled prompt for one frame to a file and actually read it. I generated for weeks without once looking at the string that goes to the model, and both faults were sitting in it, in plain English, the first time I did.