Prompt Transformation: The Prompt You Send Is Not the Prompt That Runs

An idea worth understanding even where the feature has moved on

Start with the currency note, because it changes how you should read everything below. Prompt transformation is documented as a behaviour of the DALL-E 3 image models, and DALL-E 3 was retired on 4 March 2026 — no longer available for new deployments, with existing deployments non-functional. Microsoft's own guidance now points you to a GPT-Image series model for generation instead.

So why study it at all? Because the concept is the durable part. Prompt transformation is the clearest documented example of something that is true of managed generative services in general: between the words you send and the model that produces output, there can be stages you did not write. If you believe your prompt travels to the model untouched, you will mis-diagnose every surprising image you ever get. This slice is about learning to ask what happened to your prompt on the way.

What the mechanism actually does

The feature is also called prompt revision, and it applies a safety and quality system message to your original prompt. Concretely, a large language model adds a message ahead of your text before that text reaches the image generation model. The stated goal is to enrich your original prompt so the service produces more diverse, higher-quality images while maintaining your intent.

So there are two models in the path, not one. A language model rewrites; an image model renders. Your prompt is the input to the first stage, not to the second.

The processing flow has three steps that are worth holding as a sequence. Your input prompt is revised to improve quality and add safety guidance. Content filtering then evaluates the prompt and, where applicable, the generated output. If filtering blocks the request, the service returns a response indicating the filtered category and severity. Note the ordering — the revision happens first, and filtering evaluates what comes out of it.

Why the platform does this

Two motivations, and they are genuinely distinct.

The safety motivation is that default prompt transformation includes safety-oriented guidance intended to reduce requests for disallowed content — copyrighted or trademarked characters, public figures, and categories such as sexual content, hate and unfairness, violence, and self-harm. This is a mitigation layered before the filter, shaping the request rather than only judging it.

The quality motivation is that a short prompt underspecifies an image. Microsoft's worked example is a five-word request for a watercolour painting of the Seattle skyline. The revised prompt that actually reaches the image model is a full paragraph: a setting sun casting warm hues over the cityscape, the Space Needle standing against the sky, scattered high-rise buildings, parks blending into the water of Puget Sound, the snow-covered peak of Mount Rainier in the distance, light and shadow adding depth. The documentation is explicit that this is not only a safety feature — it enriches your prompt in a more descriptive manner, leading to higher quality and more descriptive imagery.

That example also teaches something uncomfortable. Most of the detail in the resulting picture was chosen by the rewriting model, not by you. If you wanted a grey, overcast Seattle, a five-word prompt was never going to get it.

Reading the revised prompt is the debugging move

The response object carries the transformed prompt in a revised_prompt field, and it is returned whether you generated through the portal, the REST API, or an SDK. That field is your audit trail, and reading it should be the first thing you do when an image does not match your expectations.

It is also the scope test. Prompt transformation applies to image generation requests that support this field. If a deployment does not return it, prompt transformation is not available for that model — so the presence or absence of the field tells you whether a hidden rewriting stage exists at all.

Two properties you cannot change

First, on DALL-E 3 deployments you could not disable or customise it. The revised prompt was always generated automatically; there was no opt-out and no way to supply your own system message.

Second, it is non-deterministic, for the same reason the image model is — it is driven by a large language model, so a single original prompt might lead to many image variants. Two identical calls can produce two different revisions and therefore two different pictures. Any workflow that assumes byte-identical output from an identical prompt is built on a false premise.

Common mistakes

Debugging an unexpected image by rewriting your prompt over and over without ever reading the revised prompt that was actually rendered.

Assuming every image model on the platform behaves this way. The field's presence is the test, and it is tied to specific models.

Expecting reproducibility. If you need a specific image again, store the image — and store the revised prompt with it.

And inferring from the retirement of DALL-E 3 that the lesson expired with it. The lesson is that managed services can transform your input in ways you did not author, and that you should always look for the record of what actually ran.