Generating a controlled family of variants
Ask for "five variations" and you get either five clones with a different colour or five unrelated objects — the agent has no concept of which features are the brand and which are the variable, so it randomises the wrong axis.
Choose your track
Read this module through your lens
What makes objects a family
Look at a product line — a set of chairs from one maker. What makes them obviously related is not that they are identical; it is that a specific set of features is held constant (the seat height, the material palette, a signature joint) while a chosen feature varies (the back style, the colour, the arm). The constant set is the family DNA. The variable is the point of the line.
An agent does not know which features are DNA and which are the point. When you say “five variations,” it picks an axis at random — often the one you most wanted protected, like overall proportion — and leaves the intended variable barely touched. The result is either five clones or five strangers.
The advanced skill is to separate the two sets yourself and hand the agent both: this must stay identical, this alone may change.
The case study: a chair family
”Make five variations of this chair.”
Two of the five are the same chair in a new colour. Two have drifted in seat height and proportion — they no longer match the others. One has a wildly different leg count. There is no consistent axis; the family has dissolved into a pile.
”Generate five variants. INVARIANT in all: seat height 45 cm, seat 42x42 cm, oak + black-steel material set, four legs. VARY ONLY the backrest style across: slatted, solid, ladder, mesh, open-frame. Report each variant’s backrest style and confirm the invariants held.”
Five chairs that read as a family, distinguished by exactly one feature. The report flags that the mesh-back variant nudged seat depth — one invariant violation to fix, now visible because you defined the invariant.
Why naming invariants is the whole game
The instinct is to describe what should change. The leverage is in describing what must not. An invariant the agent can check (“seat height = 45 cm in every variant”) turns a vague request into a verifiable contract: after generation you read one number per variant and immediately see any drift.
This also makes the family programmatically sweepable. Once the axis is declared with allowed values (“backrest in: slatted, solid, ladder, mesh, open”), you can ask for the whole set, or sweep a numeric axis (“seat depth from 40 to 48 cm in 2 cm steps”) and get a coherent series. The agent becomes a generator with guardrails instead of a slot machine.
Add a second variable axis only when you genuinely want a grid; beyond two, “family” becomes “noise.”
Hands-on exercise
Take one of your earlier models. Write its invariant set (the features that make it itself) and pick exactly one variable axis with 4-5 allowed values. Prompt for the family, then build a small table: one row per variant, columns for the invariants and the varied axis. Mark any cell where an invariant drifted, and write the fix prompt that re-pins it.
Second case · a pendant lamp family
The same lesson, a different object
Make four variations of this pendant lamp.
Two are identical, one wildly changed the cord length, and one changed the shade material and its size at once. There is no single axis of variation — it is four lamps, not a family.
INVARIANT in all four: cord 60 cm, brass fittings, 24 cm shade height. VARY ONLY the shade silhouette across cone, dome, cylinder, globe. Report each variant's silhouette and confirm invariants held.
Four lamps that read as one product line, separated by exactly one feature. The report flags the globe nudged shade height to 26 cm — one invariant to re-pin.
Common failures · spot them fast
The failure gallery
Variants are near-identical (axis barely moved)
Variants diverge on protected features (scale, proportion drift)
Inconsistent origins/material slots across the set
Agent varies the one thing you wanted pinned
No way to tell variants apart systematically
Each of these is caught by a quality gate — keep the cheatsheet open while you work.
Worked example
See the journey
The pattern
Cheatsheet
Cheatsheet
Prompt skeleton
Generate [N] variants of [object].
INVARIANT (must be identical in all): [dimensions, proportions, material set].
VARY ONLY: [one or two axes, e.g. leg style, with allowed values].
Keep scale, origin, and material slots consistent across all variants.
Report, per variant, the values on the varied axis and confirm invariants held.
Failure modes
- Variants are near-identical (axis barely moved)
- Variants diverge on protected features (scale, proportion drift)
- Inconsistent origins/material slots across the set
- Agent varies the one thing you wanted pinned
- No way to tell variants apart systematically
Key operations
- Declare invariants explicitly (the family DNA)
- Declare 1-2 variable axes with allowed value ranges
- Reuse the same base, modify only the axis
- Verify invariants across the set (dimensions, slots)
Quality gates
- Do all variants share the invariant set exactly?
- Does variance appear only on the declared axis?
- Consistent origin + scale + material slots across all?
- Can you name what distinguishes each variant?
Workflow steps
- Separate invariants from variables on paper
- Encode both in the prompt
- Generate the set, read the per-variant axis report
- Check invariants held across all
- Cull or refine, log the family table
Next module
- product_judgment_and_handoff — deciding when it is done and handing off to the game stage.
Reflection
Reflection card
Active retrieval — answer from memory before re-reading. Saved to this browser.
You've completed this module when…
- A variant set with a stated invariant list and a stated variable axis.
- Evidence the invariants held across all variants (a small table).
- One variant where the agent broke an invariant, and the fix.
Next: product_judgment_and_handoff — deciding when it is done and handing off to the game stage.
Finish — back to Product Design →