The bounded enhancement-and-QA loop

Routing answers whether an image should be enhanced. This chapter explains what happens after the image takes that route. Enhancement is not a single call to an image model. It is a controlled loop with three stages:

1. Generate an image-specific prompt.
2. Edit the image.
3. Check the result with multidimensional QA.

If QA finds a problem, its feedback is sent back into another enhancement attempt. The loop is allowed to run only up to a bound, written here as K. The goal is not to keep generating forever. The goal is to improve the image when improvement can be produced safely, and to stop when it cannot.

1. Build a prompt for this image

The enhancement stage starts with information already produced by the earlier routing process:

• the image's description; and
• the routing directives, which describe the enhancement decision or requirements.

The system uses these inputs to generate a prompt for the edit. The important property is that the prompt is image-specific. It is derived from what this particular image contains and what this particular image needs. It is not simply one generic instruction applied to every merchant and every dish.

That distinction matters. A generic prompt can push different images toward the same visual style. An image-specific prompt gives the editor a narrower target: improve the relevant problem while staying connected to the source image and its description. The source does not disclose the exact prompt format or the routing-directive schema, so the mechanism should be understood at this level rather than as a specified template.

2. Edit the image

The editor receives the generated prompt and produces an enhanced image. “Enhanced” does not mean “changed as much as possible.” A useful edit must improve the intended aspects without breaking the content or appearance that should remain faithful to the source.

For example, a prompt may be aimed at improving the presentation of a dish. The editor still needs to preserve what the dish is and how it is represented. A more polished result is not automatically a better result if it changes the portion, removes an important element, or introduces content that was not present.

The editor's first output is therefore a candidate, not an automatic publication decision. The next stage checks whether the candidate meets the required conditions.

3. Check several dimensions, not one score

The QA gate evaluates the generated image across multiple dimensions. The speakers name plating, faithfulness, and colors as examples of these checks.

• Plating asks whether the food's presentation is appropriate.
• Faithfulness asks whether the edit stays true to the source and its intended content.
• Colors asks whether the color treatment remains acceptable rather than becoming misleading or unnatural.

These dimensions are related, but they are not interchangeable. An image can have attractive colors and still fail faithfulness. It can preserve the content and still have poor plating. A single aesthetic score could hide these different failure modes, while separate QA dimensions make the reason for rejection more useful to the next edit.

The QA gate consequently produces more than a vague impression of quality. It produces feedback about what the editor should reconsider.

Click to enlarge

Source visual at 13:37 — The visible diagram directly represents the flow described here: generate an image-specific prompt from the description and directives, enhance the image, and evaluate it through a multidimensional QA gate. Failed results are routed back for another attempt using QA feedback.

4. Feed QA feedback into the next attempt

When the result fails QA, the system does not start an unrelated generation process. It combines the QA feedback with the initial enhancement inputs and sends that information back to enhancement.

The dependency looks like this:

image description + routing directives
                    │
                    ▼
          generate image-specific prompt
                    │
                    ▼
                 edit image
                    │
                    ▼
          multidimensional QA gate
             │                 │
          pass              fail
             │                 │
             ▼                 ▼
       accept result     add QA feedback to the
                         enhancement inputs and retry

Feedback makes the loop corrective. It tells the next attempt which requirement was missed. Without that feedback, repeated attempts would be repeated guesses. With it, the editor has a stated reason to change its next output.

The source does not describe the exact QA message format or the internal prompt-construction procedure. It does establish the control flow: QA feedback returns to enhancement together with the relevant original inputs.

5. Stop after a bounded number of iterations

The retry loop has a maximum of K iterations. The transcript does not give a numeric value for K. This bound is important because an open-ended self-correction loop could spend unbounded compute and latency while still failing to produce a suitable image.

At the end of the bounded process, there are two outcomes:

Pass within K: publish the enhanced result

If one of the attempts passes the multidimensional QA checks within the allowed bound, the system can publish that passing enhanced result to the next stage of the production workflow.

Still failing at K: do not force enhancement

If the attempts continue to fail, the system stops enhancing the image. The speakers describe this as taking a coverage hit. In practical terms, fewer routed images receive a successful enhanced result. That is an accepted cost of refusing to force a bad output through the system.

This is a deliberate tradeoff:

Choice	Benefit	Risk or cost
Allow more iterations	More chances to correct the image	More compute and latency, with possible over-editing
Stop at K and withhold the enhancement	Prevents a known failing result from being forced into publication	Enhancement coverage is lower

The bound therefore turns the editor into a bounded improvement process, not an unlimited generator. The system gives the model opportunities to correct itself, but it retains a safe stopping rule when those opportunities are not enough.

Click to enlarge

Source visual at 14:06 — The diagram shows the closed-loop enhancement process: a generated prompt is used for enhancement, the result is checked against several criteria, and a failed check loops back with QA feedback. The visible diagram does not show the transcript's K-iteration limit, publication branch, or coverage-hit outcome; those details come from the spoken workflow.

Keep this QA loop separate from the final publish gate

This enhancement-stage QA loop answers a local question: Can the editor produce an acceptable enhanced image, and if not, can feedback correct it? It is not the same as the final publish-ready QA described later in the lesson.

The distinction is useful:

Stage	Question it answers
Enhancement-stage QA	Does this edit satisfy the required image-quality dimensions, or should it be retried?
Final publish-ready QA	After the workflow is complete, is the item ready to enter production?

The first gate helps the editor improve or stop. The later gate provides another defense before publication. Passing one should not be treated as proof that every later production check is unnecessary.

The mental model

The bounded loop combines agentic editing with explicit control:

describe and route
        ↓
create a prompt for this image
        ↓
edit
        ↓
check plating, faithfulness, colors, ...
        ├── pass → continue with the accepted enhancement
        └── fail → include QA feedback and retry, up to K
                              └── still failing at K
                                  → stop enhancing; accept lower coverage

The central idea is not that the editor always succeeds. It is that every attempt is checked, every failure can inform a bounded retry, and persistent failure has a conservative outcome. This lets the system seek useful visual improvement without treating model output as publishable merely because the model produced it.