What should architects do with a client's AI image?
Convert it into an assumption log before designing from it. Separate confirmed preferences from inferred requirements, list unknown site and program conditions, flag elements that need technical proof, and record what must not be copied. Ask the client to confirm the written interpretation rather than approving the image as a whole.
A client opens a meeting with a glowing house beside an implausibly still lake. The glass has no frames, the cantilever has no appetite for structure, and the sunset has apparently waived the planning code. “Something like this,” they say.
That image may be enormously useful. It may also contain six mutually incompatible instructions. The professional move is neither dismissal nor obedience. It is translation.
Why are client AI images showing up now?
A May 2026 Architect Magazine article says clients increasingly arrive with AI-generated visuals and pre-formed concepts. The page is explicitly brought to readers by Chaos Software, so treat the trend statement as a sponsor-backed industry claim, not a measured census.
The mechanism is plausible. Image generators have made architectural mood cheap and immediate. A client can arrive with twenty polished options before a survey exists. Production has moved ahead of definition.
The problem is that image fluency looks like design resolution. Photorealism compresses doubts. A convincing shadow can make an unsupported roof feel decided, while a complete-looking room conceals the absence of dimensions, access, services and budget.
Our guide to client expectations addresses the broader shift. The assumption log is the small document that handles the first meeting.
An attractive image is not a coordinated brief
NCARB's project-development competencies distinguish communication from documentation. Architects are expected to communicate a proposed design through appropriate media, then develop coordinated instruments that convey requirements and guide construction. The client's generated image sits before that sequence. It communicates desire without coordinating consequences.
Do not ask, “Do you like this?” The answer is already yes. Ask what the client believes the image promises. Is the priority the low roofline, the amber light, the privacy, the stone, or the fantasy of a room with no visible storage?
A useful interview moves from visible feature to intended effect. “Do you want this much glazing?” is weaker than “Is the goal a continuous view, more daylight, or a minimal frame?” Three different goals may require three different buildings.
What belongs in the assumption log?
Use one row per consequential feature. Quote the client's words where possible. Assign each row a status and an owner for the next check. Keep the source image marked with simple callouts so the written row can be traced to a visible region.
| Status | Meaning | Next action |
|---|---|---|
| Confirmed intent | The client states the desired outcome | Add it to the brief in words |
| Visual preference | A mood, material character or proportion is liked | Collect references and define tolerance |
| Assumption | The team inferred a requirement from pixels | Ask the client to confirm or reject it |
| Unknown | Site, program, cost or performance data is absent | Assign research or consultant input |
| Proof required | The image implies a technical promise | Test it before repeating the visual |
Add a sixth status when needed: excluded. The image may show a pool, furniture, mature planting or a neighboring view that sits outside scope. Silence is a generous architect. It gives everything away.
The log should include source and date. If the client generated the image, record that. If they found it elsewhere, ask about provenance and permission before the team republishes or closely imitates it. The image can inform discussion without becoming an anonymous design asset.
How do you separate preference from promise?
Mark atmosphere, geometry and performance separately. Warm evening light is atmosphere. A six-metre frameless opening is geometry. Comfortable summer conditions behind that glazing are a performance claim, whether anyone intended to make it or not.
Material appearance needs the same split. “Pale monolithic stone” may be a preference. Joint-free corners, impossible panel spans and identical texture across every face are promises smuggled in by generation. The reference-image brief helps assign each reference one job; the assumption log identifies jobs the image cannot perform.
Ask the client to rank two priorities when the image conflicts with reality. If uninterrupted glass and low cooling load collide, which outcome carries more weight? If a deep cantilever competes with a strict cost limit, which assumption moves?
This is not the moment for a lecture on hallucination. It is a design conversation with sharper nouns.
What should be redlined before modeling?
Trace the elements that could become expensive expectations: overall massing, floor count, opening pattern, span, roof thickness, external space, apparent site relationship and significant built-ins. Use labels such as “preference,” “to verify” and “outside scope,” not a haze of red circles.
Next, identify camera tricks. A wide field of view can make a modest room look palatial. A missing neighboring building creates privacy that the site does not possess. Unusually low furniture can exaggerate ceiling height. Note the effect without pretending to know the generator's settings.
Then mark contradictions. The image may combine a flush threshold with a climate, drainage condition or accessibility requirement that demands detailing. It may show mature trees on a slab or a fireplace with nowhere for the flue to go. These are prompts for investigation, not instant verdicts.
Should the image enter the model?
Only after its role is named. It can sit beside the model as a style reference, camera cue or discussion record. It should not silently become geometric authority.
SketchUp's current AI Render documentation is unusually clear about the distinction: a reference image can define stylistic output, while a separate control governs how much generated output respects model geometry. Style and geometry are different controls even inside one tool. A client image deserves the same separation outside it.
If the team uses the image to generate further options, preserve the original, prompts when available, output dates and selection notes. Our visual decision log carries that record through later rounds.
How does the client confirm the translation?
Send a one-page log after the meeting. Ask for confirmation of each “confirmed intent” and resolution of the largest assumptions. Do not request approval of the whole image. Whole-image approval turns every unmentioned pixel into tomorrow's disputed memory.
At the next presentation, show how the first design response addresses the confirmed intents. Place unresolved technical questions beside the relevant view. This keeps visual momentum without confusing a compelling reference with a coordinated solution.
The log is allowed to change. Its value is not permanence but provenance: the team can see which idea came from the client, which was inferred, which was tested and which was dropped.
Our take: admiration is not authorization
A client-made image can be a better opening sentence than a page of adjectives. Give it that credit. Then put it through the ordinary discipline of architecture: brief, constraint, test and decision.
Keep the picture. Retire its alibi.