Hold the invariant, vary the delta

Tags: consistency, identity, regeneration

Left alone, every regeneration varies everything. So a change to one attribute arrives bundled with incidental changes to all the others — the user wanted the same character in different armour and got a stranger. Nobody decided identity should drift. Nobody decided it shouldn't, either, and in a generative product the default is drift.

Consistency is a decision, not a setting

It is tempting to treat this as a model problem: turn down the randomness, lock a seed, pick a more consistent model. Those are real tools. But none of them answers the question that actually determines whether regeneration works, which is what, specifically, is supposed to stay the same?

That question has no technical default. It depends entirely on what the user is doing:

Refining a character's gear — the face must hold; the equipment changes.
Trying lighting on a product shot — the product must hold; the scene changes.
Redrafting a paragraph — the argument must hold; the phrasing changes.
Adjusting a brand campaign — the voice must hold; the offer changes.

In each case the delta is the thing the user is adjusting and the invariant is everything else they have already accepted. Get the split right and a regeneration reads as the same thing changing. Get it wrong and it reads as a different thing.

Too little, too much

Choosing the invariant is a genuine design trade, and it fails in both directions.

Hold too little and nothing is recognisable between versions. Each regeneration is a fresh draw; the user cannot iterate, because there is nothing stable to iterate on. This is the default, and it is why so many generative tools feel like slot machines.

Hold too much and the change cannot happen. A seed locked so hard that the new armour inherits the old armour's silhouette has made consistency at the cost of the edit the user asked for.

The right split is narrow and task-specific, which is exactly why it has to be designed rather than configured.

Make the invariant visible

Holding something fixed only helps if the user knows it is being held. Otherwise they cannot tell a deliberate constant from a coincidence, and they cannot reason about what their next change will affect.

The simplest forms of this are small: character locked, a pinned reference image, a "keep the tone of the original" control that is visibly on. Each tells the user what they can rely on staying put — which is the thing that lets them change the rest with confidence.

Grounded in

Pathfinder is a character builder whose portraits regenerate whenever the loadout changes. It locks the base portrait seed and varies only the equipment in the prompt — the trick that makes a swap read as the same character changing clothes rather than a new roll of the dice.

What is worth drawing out is that this was a chosen split, not a tuning outcome. The face and body are the invariant; the loadout is the delta. That choice follows directly from what the product is for: a character builder whose hero changes face every time you re-equip is not building a character, however good each individual portrait is.

Regeneration is an edit, not a retry touches the same mechanism from the other side — what a second attempt produces. This is the prior question: what that attempt is allowed to change.

Anti-patterns

Everything varies. The default, and the reason regeneration feels like gambling.
Consistency treated as a model setting. Lower temperature and a fixed seed, with no decision about what should actually be held.
Locking so hard the edit cannot land. Consistency achieved by preventing the change the user asked for.
An invisible invariant. The user cannot tell what is being held, so they cannot predict what their next change will affect.
One invariant for every task. What must hold while changing gear is not what must hold while changing lighting.

The smallest version worth building

For each regeneration action, write one line: this changes X, and keeps Y. Implement Y as the held constraint — a locked seed, a reference, a preserved passage — and show it in the interface.

The one line is the design. Everything technical follows from having written it down.

Regeneration is an edit, not a retry — what a second attempt produces; this is what it is permitted to change.
Decide what counts as the same request — the invariant is also part of what makes two requests "the same".
The character is a state machine — a persona is another thing whose identity has to survive every state it passes through.