The specification-first image pipeline

Vision models generate and interpret images, but they fail in the exact manner earlier lessons taught us to anticipate: their output looks convincing regardless of whether it is accurate. A model might miscount items, omit a required subject, or drift into an unintended visual style, yet the resulting image appears completely coherent. Generative machinery naturally optimizes for plausibility across pixels just as it does across prose. Because an image will never announce its own omissions, validation must come from an independent system outside the generating model.

In this module, we construct an architecture designed specifically to provide that verification. The workflow coordinates three distinct roles. First, the designer writes a detailed specification in structured text before calling the generator to produce pixels. Next, the blind observer inspects the generated image file with zero knowledge of what was requested and records an inventory of what actually appears. Finally, the conformance auditor reads that inventory against the specification to determine whether the image meets the requirements, reaching an audit verdict without ever viewing the image. We call this architecture the division of visual labor. By the end of this lesson, you will be able to evaluate any automated visual review, identifying which role conducted the inspection and what information it was given beforehand.

We examine this architecture through a concrete production run, which generated the specimen you will evaluate later in this module. The task requested three phosphor-green amphorae on a stone shelf against a dark virtual terminal space, processed through an image production team of agents. An amphora is a traditional two-handled Mediterranean vessel used historically to transport wine and oil; here, the critical detail is the exact count of three, providing an unambiguous metric for verification. In this team, the designer coordinates the generator tool and delegates review across isolated steps, enforcing strict boundaries on what each component is allowed to see.

One statement about this module’s numbers and pictures, made once. The amphorae run, its specification fields, and the 57-out-of-100 score computed from that run’s eight fields (seven checkable, four matched) come from a live run on 2026-07-11; the trace you will inspect is reconstructed from that run. Two elements are constructed to illustrate specific mechanisms: the priming case, where a reviewer instructed to look for three vases reports three on an image holding two, and the four-row audit table with its 5600K lighting field and patterned wall, neither of which comes from the run. The pipeline diagram also idealizes two runtime behaviors: it illustrates a single pass where a production session loops back to phase 1 when the audit recommends regenerate and you agree, and it positions the blind observer alongside the conformance auditor to emphasize their separation, even though the auditor runs only after the observer has written its inventory.

the pipeline separates designer, observer, and auditor

Consider an execution run where a user asks for three amphorae resting on a stone shelf. The generation model returns an image displaying two amphorae, rendered cleanly against the background. If we present this rendering to a multimodal model alongside the original request and ask whether the output is correct, the model will tend to confirm the match. Tokens from the user’s prompt occupy its active context, priming attention toward the expected subjects; the model easily glosses over the missing amphora or assumes that the third vessel sits just outside the frame. To evaluate the image reliably, we must decouple observation from expectation. The system requires an inspection performed by an agent that has not been told what to expect, followed by an independent check that evaluates those observations against the original requirements.

To enforce this separation, the pipeline divides execution across three specialized stages.

When an incoming request arrives, the designer does not call the rendering tool immediately. It first drafts a specification: a structured JSON document defining explicit subject counts, lighting, color palette, background, composition, aspect ratio, and the master generation prompt. The designer’s instruction then tells it to stop and wait for your explicit approval.

Once you approve the specification, the designer calls generate_image, saving the resulting file to disk.

Review is a third phase, and it runs when you ask for it. The designer then calls inspect_image with the saved file path and nothing else, and the tool hands the file, along with a fixed six-section inventory protocol, to a blind observer. This vision model receives the image and that protocol; neither the user’s initial prompt nor the approved specification enters its context window. Because the protocol names categories and no target, the observer describes what it sees in those six categories: subjects with their counts, composition, light, palette, medium cues, and any lettering or artifacts. It returns a descriptive inventory in plain text without judging whether the image satisfies the task.

The designer then delegates to a conformance auditor, passing it the inventory and the approved specification verbatim. The auditor is a text-only model that never inspects the image file. Reading both documents, it compares the observed visual facts against the declared constraints field by field and emits three outputs: a structured verdict for each field, an overall conformance score, and a recommendation that is either accept or regenerate with the one spec field to reinforce.

phase one: decide the specification in writing

Why should we construct a formal specification when the user has already provided an instruction in natural language? The answer is that ambiguous prose cannot be tested rigorously. If we prompt directly with informal requests like “make it look professional,” the resulting image remains unpredictable; worse, you have no clear standard for verification, because the criteria for success were never defined. Verification requires an explicit contract, and that contract must exist before the output is produced.

The Riverside Community Fair, the course’s fictional practice event, sends the designer one line for its poster: “Make it look professional.” Pass that line to an image model and you get a poster, and nothing written down to check it against.

The conformance auditor will later compare an inventory of the poster, a list of what is visible in it with exact counts and placements, against whatever was written down before the poster existed.

Consider the specification written for our amphorae run before rendering began. The core requirements were defined across distinct fields: primary_focus specified exactly three ancient Greek amphorae evenly spaced; location defined a virtual dark terminal space; medium designated a CRT vector-graphics render; color_palette required monochromatic phosphor green on pure black; and aspect_ratio set a 16:9 frame. Each of these five fields makes an empirical, verifiable claim. An assertion such as “evenly spaced” can be checked objectively; an adjective like “nice” cannot.

To enforce this standard, the designer’s system instruction divides its work into phases. The excerpt below quotes the phase headers and the rules that govern the two tools, taken from the ImageDesigner instruction in the team definition; […] marks the lines left out.

### PHASE 1: DESIGN & CONFIRMATION (First Turn or Payload Tweaking)
When the user first requests an image, or when they request changes to an existing design, you must **NEVER** call the 'generate_image' tool. […]

### PHASE 2: GENERATION (Only Upon Explicit Confirmation)
5. **ONLY** when the user explicitly approves the design (e.g., saying "build it", "approve", "generate", "yes", "looks good", "go ahead"), call the 'generate_image' tool. […]

### PHASE 3: REVIEW (Upon User Request, After Generation)
8. When the user asks to review, audit, or verify the generated image, call the 'inspect_image' tool with the saved file path — and NOTHING else. […]

Read that as: the agent moves through three states, and the tool that makes pixels is forbidden in the first one. The instruction tells the designer to render nothing until a person has read the fields and said yes, and to inspect nothing until a person asks for the review.

This brings us to a foundational rule of reliable generation:

Write the contract before anything renders. Define visual requirements in a structured schema before the first render. Verification requires an explicit contract to compare against; a field that was never written down can neither match nor fail.

This design relies on two patterns already in your hands. The structured phases are a workflow-stages block that steers tool sequencing across conversation turns. The required confirmation step is input-stage discipline: a person checks the constraints before any rendering begins. In the specimen both live in the designer’s instruction, so they shape what the model tends to do and no code checks them: the team definition declares no gate, and generate_image runs whenever the model calls it. The same holds in phase 3, where calling inspect_image before the auditor and passing both texts verbatim are instructions too. When the order has to hold, you declare it in the team definition: the runtime’s require_approval key, naming generate_image, ends the task waiting for input before that call runs, until a person answers approve or reject. The gate approves the call and its arguments; it does not check that a phase-1 specification was shown first, so the prompted phases still carry that part. Correcting an assumption during specification costs a single prompt edit, whereas fixing errors post-generation requires re-rendering.

Form this operational habit early: before requesting an image, define the exact fields you intend to grade. If a visual requirement cannot be stated in clear words, it has not yet been decided, and that ambiguity is precisely where generation will fail.