A generated interior shows late-afternoon light cutting across a concrete floor. The client points to the bright rear wall and says the room clearly gets enough daylight. The image feels persuasive because the light has direction, softness, color, and a plausible patch of sun.

But the model did not necessarily know the building location, date, hour, glazing transmittance, surrounding obstruction, blind state, surface reflectance, or annual weather file. It made a picture that reads as daylight. That is not the same job as calculating daylight.

Today's intel sweep is full of tools and workflows that promise better lighting, faster material studies, and photorealistic results. Chaos describes Veras as a way to explore lighting and design ideas, while community requests for ComfyUI workflows repeatedly ask for improved light, reflections, and atmosphere. Those are legitimate visualization tasks. Trouble begins when the output crosses the review table without a label and starts acting like performance evidence.

Two useful tools, two different questions

AI relighting asks a visual question: what might this space feel like under a selected lighting condition? It can help a team compare a cool overcast mood with warm evening light, test whether a material palette still reads at lower contrast, or communicate the intended character of a lobby.

Daylight analysis asks a quantitative question: how much illuminance reaches defined points, for how much of the occupied period, under a stated climate and operating assumption? The Illuminating Engineering Society's LM-83 method defines climate-based metrics including spatial Daylight Autonomy and Annual Sunlight Exposure. The method requires standardized inputs, sensor points, annual weather data, time periods, thresholds, and assumptions about daylight controls.

A rendered image does not become an annual calculation because it looks physically coherent. A simulation does not become a persuasive client image because it contains accurate numbers. Practices need both, with the boundary visible.

OutputIt can supportIt cannot establish
AI-relit imageMood, composition, visual direction, discussionAnnual daylight sufficiency or glare compliance
Single physical renderA stated sun and sky conditionPerformance across the year
Climate-based simulationMetrics under recorded assumptionsThe exact visual mood a client will perceive
Field measurementConditions at a measured place and timeEvery future weather and operating condition
AI relighting can propose the question. Daylight analysis has to answer it with location, time, geometry, materials, weather, and a metric.

Run the five-line caption test

Before an AI-relit image enters a pin-up, client deck, planning submission, or design report, add a compact caption. If the team cannot write these five lines, the image is still an unbounded impression:

  1. Purpose: visual mood study, material study, presentation image, or analysis illustration.
  2. Source: named model view, render, sketch, or photograph used as the input.
  3. AI operation: relighting, image-to-image generation, local edit, or full regeneration.
  4. Fixed facts: geometry, camera, openings, and materials that were intended to remain unchanged.
  5. Evidence limit: not a daylight calculation, unless a separate cited analysis supplies the values.

The final line matters. It stops a visual from quietly acquiring authority as it moves away from its maker. The project architect may understand that an image is exploratory. A client, juror, contractor, or future team member may not.

Watch the parts AI may quietly change

Relighting often changes more than illumination. A generative pass can widen a highlight, remove a mullion, lighten glazing, invent a reflected opening, smooth a soffit, or make the exterior beyond a window brighter than the stated sky would allow. Even if the overall geometry looks stable, local edits can alter the very features that govern daylight.

Openings and obstructions

Check every window head, sill, mullion, reveal, fin, canopy, and adjacent mass. Small geometric changes can have a large effect on the story an image tells about light penetration. Use an overlay against the source view rather than relying on memory.

Surface brightness

A pale wall can appear to throw light deep into a room, but an AI pass may simply lift local exposure. Record the intended finish and keep the simulation material values separate from the presentation grade. A bright pixel is not a measured reflectance.

Sun position

Trace the shadow direction. Does it correspond to a plausible sun angle for the site and stated moment? If the image is only atmospheric, say so. If it claims a date and hour, generate or render that condition from a model that can calculate it, then treat any AI pass as post-production that must preserve the shadow logic.

Use a paired deliverable

The cleanest workflow is not to ban AI light studies. Pair each kind of evidence with the job it does best.

First, use AI to create a small visual question set. Keep the camera and main geometry fixed. Ask for three clearly named conditions, such as overcast morning, clear winter noon, and warm evening presentation. Use these to discuss atmosphere, material contrast, perceived depth, and where the team wants attention to fall.

Second, turn any performance question raised by those images into a simulation task. If the rear of the plan appears dark, test daylight sufficiency across the occupied zone. If a low sun creates a dramatic patch, test excessive exposure and glare risk under the project's chosen method. If external fins appear effective, compare the geometry with and without them under the same inputs.

Third, place the image and result side by side. The visual gets a caption describing its generative treatment. The analysis gets a caption naming software, model revision, climate file, metric, threshold, analysis period, material assumptions, controls, and author. Do not blend the two legends.

Do not paint over a failed result

A common temptation is to use the analysis, dislike its dark appearance, and send the view through an AI enhancer until it looks inviting. That can be acceptable for a separate presentation image. It is not acceptable as the graphic attached to the original numerical claim unless the altered areas are disclosed and the analysis values remain independently available.

The reverse is also risky. A compelling generated image may prompt the team to adjust a simulation until it seems to validate the picture. Inputs should come from the project and agreed assumptions, not from the desired aesthetic outcome. Let disagreement between the render and the calculation expose a question. Do not tune one into a costume for the other.

Our take: protect the useful ambiguity

AI light studies are valuable precisely because they are fast and suggestive. They let a team consider mood before every specification is fixed. Forcing them to behave like analysis makes them less honest, not more rigorous.

Daylight simulation has a different value. Its assumptions can be inspected, repeated, challenged, and revised. The current IES method exists so that terms such as spatial Daylight Autonomy refer to defined calculations rather than a general impression of brightness.

Keep the AI image. Put the weather file on the next page.


Editorial basis: the 26 September 2026 ArchiGen AI intel sweep, including current Chaos Veras product material describing lighting and design exploration, and the Illuminating Engineering Society LM-83 method defining climate-based daylight metrics and inputs. Product capabilities are vendor claims. This article reports no hands-on test and makes no claim that a specific AI tool performs daylight analysis.