Preventing invention in visual generation systems

Most discussion of generative image quality assumes the failure looks like failure — a warped hand, a melted chair, an obviously synthetic room. In visual commerce the dangerous output is the opposite. It is beautiful. It is exactly what the shopper wanted. And the retailer does not sell it.

That output costs more than a bad one. A visibly broken image gets ignored. A convincing image of a sofa nobody stocks produces a shopper who has decided, a sales team who cannot fulfil, and a conversation that begins with an apology. The system did not fail loudly enough to be caught.

So the engineering problem in a visual commerce system is not fidelity. It is constraint: the generated room may contain the retailer's catalogue and nothing else.

The instinct is to solve this in the prompt — describe the product carefully enough and the model will render that product. It does not hold. A prompt is a request, and a generative model treats a request as a starting point rather than a specification. Under pressure from the rest of the scene it will drift toward the plausible, and plausible furniture is furniture in general, not this catalogue's.

In the AI Space Visualizer, placement is decided before generation is asked for anything. The room is analysed from a single uploaded photograph, positions are derived from what the room can physically take, and products are matched to those positions from the catalogue the retailer actually stocks — in the sizes they stock. Generation composes a decision that has already been made. It is the last step, not the mechanism.

This is the same shape as the retrieval argument in RAG systems, and it generalises: whenever a model's output has to correspond to something real, the correspondence is established by the system around the model, and the model is given the narrowest possible job.

A catalogue will sometimes have nothing that fits — the room is too small, the position needs a piece in a size nobody stocks, the category is empty. The honest response is to say so.

This is unpopular to build, because it is a feature whose success looks like nothing happening. But the alternative is inventing, and the alternative is what the whole system exists to prevent. A visual commerce tool that always produces a room has quietly stopped being constrained to the catalogue; it has only stopped telling you when it left.

Generation costs money per call and fails in ways tests do not reproduce. The controls that make it safe to leave running are unglamorous and are the difference between a demo and a product: budgets per day and per visitor, a switch that stops generation without a deploy, and logs that record what was actually sent rather than what the code appears to send.

That last one earns its keep repeatedly. The most expensive bugs in this class of system are invisible from every reading that looks plausible — the code, the configuration and the dashboard can all agree while the thing that actually went over the wire was different. Reading the request that was really made, and the body of the response that really came back, is what settles it.

A shopper photographs a room and sees the retailer's real, in-stock products in it. They revise by describing the change rather than learning a layout editor. The finished design reaches the sales team with the products already identified, so the conversation starts from a specific room and a specific list.

None of that is possible if the model is allowed to invent. All of it is straightforward once it is not.