I did what most people do first. I rewrote the prompt. Then I made it longer. Then I added negative instructions. The output changed, but the uncertainty did not.

The actual bug was my process. I was changing several inputs at once and judging the result from memory.

So I stopped treating reference images as inspiration and started treating them as test inputs.

What I mean by a test harness

This is not an automated benchmark and it does not make image generation deterministic.

It is a small structure around the experiment:

• a fixed prompt version

• named reference roles

• one changed variable per run

• explicit acceptance checks

• a short result log

The goal is not to prove that one image model is universally better. The goal is to answer a narrower question: which input changed this output?

That sounds obvious, but it immediately rules out the workflow that caused most of my confusion: replacing two references, tweaking the prompt, and changing the aspect ratio before pressing Generate again.

Start with a manifest, not a mood board

A mood board is useful for direction. It is bad at documenting causality.

Before a run, I now write a tiny manifest. It can live in JSON, YAML, a note, or even a filename. Mine looks roughly like this:

{
  "prompt_version": "v3",
  "canvas": "4:5",
  "references": {
    "subject": "subject-a.png",
    "scene": "scene-c.png",
    "style": "style-b.png"
  },
  "must_keep": [
    "subject identity",
    "dark green coat",
    "waist-up framing"
  ],
  "allowed_to_change": [
    "background details",
    "small accessories"
  ]
}

The labels matter more than the format.

Calling an image subject-a.png forces me to state what I expect it to control. Without that label, a visually strong image can quietly become the source for lighting, crop, clothing, and camera position at the same time.

Step 1: Build a boring baseline

The baseline should be easy to understand, not beautiful.

I begin with the prompt only, or with the single reference that defines the most important constraint. If identity is the priority, that is the subject reference. If layout is the priority, it may be a rough composition sketch instead.

The baseline gives me something to compare against. Without it, I tend to credit the full reference stack for qualities that the model would have produced anyway.

I save the baseline before adding anything else.

Step 2: Add references one role at a time

My usual order is:

1. subject

2. composition or scene

3. style

4. material or detail

The order is not a universal rule. It is simply a stable order that makes the log readable.

Each run changes one slot. The prompt, canvas, and other references remain fixed.

If adding the scene image changes the character's face, that is useful evidence. The scene image is carrying a subject signal I did not intend to import. I can then replace it with a quieter scene reference instead of trying to repair the face with another paragraph of prompt text.

This was the biggest improvement in my workflow: a bad result became diagnostic information rather than a reason to add more instructions.

Step 3: Separate hard checks from preferences

I used to rate an output with one vague question: “Do I like it?”

That mixes failures with taste.

Now I use two groups.

Hard checks

These are pass or fail:

• Is the intended subject recognizable?

• Is the required object present?

• Is the aspect and framing usable?

• Did any forbidden text or logo appear?

• Did the composition keep the important spatial relationship?

Preferences

These can be scored:

• lighting

• color harmony

• material quality

• visual energy

• stylistic match

An output can pass every hard check and still be unattractive. It can also look excellent while failing the one requirement that matters for production.

Keeping those judgments separate prevents a beautiful failure from winning the test.

Step 4: Record the delta, not the whole image

Long notes slow the experiment down. I record only what changed from the previous run.

This table gives me a decision path.

Run C tells me the original scene reference was not necessary. Run D tells me the style image is too influential, so the next test should replace or simplify that image. I do not need a new prompt yet.

The tool is part of the environment, not the conclusion

For disclosure: I run a reference-image generation workspace called Whisk AI, and I used it for these tests because it keeps subject, scene, and style inputs visibly separate.

That means this is not a neutral product comparison.

The method should transfer to any image system that accepts one or more visual references, but the exact influence of each slot will vary by model. Some systems also expose seed, reference strength, or control weights. If those settings are available, they belong in the manifest and should remain fixed while testing another variable.

What did not work

Chasing the same image twice

Even with identical inputs, a generative model can produce different details. I stopped expecting pixel-level reproduction. The checks need to focus on stable requirements such as identity, layout, and object presence.

Scoring too many qualities

My first scorecard had twelve dimensions. I spent more time rating than generating.

Five hard checks and three or four preferences are usually enough. If a criterion cannot change the next decision, I remove it.

Using a “perfect” reference

The most polished image is often the noisiest test input. Editorial lighting, a dramatic crop, and complex styling may all leak into the result.

A plain image with one clear job is often easier to control.

Changing the prompt to rescue every run

A prompt edit is another variable. If I change it, I label it as a new prompt version and start a new comparison branch. Otherwise the log becomes fiction.

A compact procedure I can repeat

Here is the whole loop:

1. Define one production goal.

2. Write three to five hard acceptance checks.

3. Freeze the prompt, canvas, and model settings.

4. Generate a baseline.

5. Add or replace one reference role.

6. Record only the useful and harmful delta.

7. Keep the change, revert it, or test a quieter replacement.

8. Start a new branch only when changing the prompt.

The procedure is deliberately small. It needs to survive a real deadline.

The useful outcome is an explanation

A good run is helpful. An explainable run is reusable.

Once I can say, “the second scene reference improved depth but weakened identity,” I have an actionable next step. I can replace that reference, reduce its influence if the tool allows it, or accept the tradeoff.

Without the test harness, I only have a folder full of images and a vague memory of what I tried.

The method will not remove randomness from image generation. It does remove a large amount of randomness from the way I debug it.

If you use a similar workflow, I would be interested to know which acceptance checks remain useful across different models and which ones are too tool-specific.