I did not start this research with an abstract benchmark. I started with a very concrete problem.

Part of my work involves real estate. Property photos are not always well lit, shot from a good angle, or taken after the space has been fully cleaned. To get a listing online quickly, I sometimes ask ChatGPT to help edit the images.

But if I simply say, “Make this photo look better for an Airbnb or Zillow listing,” the model may improvise. It can add furniture, plants, and decorations, or turn an empty room into a staged interior that has never existed.

That is not what I want. The actual request may be much more specific: preserve the empty-room state, remove clutter, improve exposure and white balance, correct the perspective, and make the image easier to present without changing the facts of the property.

The problem becomes harder when the same room has left, center, and right views. If the three images are edited independently, doors, windows, fixed fixtures, furniture, and spatial relationships may no longer agree.

So the question is not simply “How do we write a better prompt?” It is:

When a user’s request is incomplete, when should an LLM ask a few questions before acting, and when should it just start?

The short answer

In the current experiment, using 12 frozen tasks and two generator models, the most stable result was not that PPN produced the best quality. It was the cost and latency ordering:

One-shot was the cheapest, PPN was in the middle, and IDR was the most expensive. PPN’s quality advantage did not replicate consistently across models.

The current evidence does not support forcing every request through PPN. A more sensible product direction is an adaptive clarification layer: execute simple, well-specified tasks directly, and ask a small number of high-value questions when ambiguity, constraints, or external risk make them worthwhile.

This was a limited Stage A controlled experiment, not a universal claim about every model or task. The real-estate image scenario is the motivation and product direction for the research; it has not yet been directly validated by this text-only experiment.

Three ways to collaborate

To study when information should be disclosed, I represented the same task in three protocols. The protocols used the same final facts, hidden constraints, and acceptance criteria. The only thing that changed was when information became available.

One-shot: provide everything and act

The user provides the complete specification at the beginning, and the model executes the task directly. This is closest to an ordinary, explicit instruction.

PPN: ask before acting

PPN stands for Pre-task Prompt Negotiation. The model first identifies missing information that could affect the result and asks a set of pre-execution questions. After receiving the answers, it executes the task against the confirmed specification.

The goal is not to make the model chat more. It is to make the task contract explicit before work begins.

IDR: act first, then repair through dialogue

IDR stands for Iterative Disclosure and Repair. The model creates an initial result from incomplete information. The user then adds requirements step by step, and the model revises the result.

This resembles everyday conversation more closely, but it can repeatedly resend context, regenerate outputs, and spend tokens repairing problems that might have been prevented earlier.

How the experiment worked

Stage A used 12 frozen synthetic tasks covering:

• ordinary and technical writing;
• Python programming and bug fixing;
• data analysis;
• JSON extraction;
• publishing plans;
• decision analysis;
• customer communication.

Each task and protocol was run three times with two generator models:

• deepseek-v4-flash;
• kimi-k2.6.

That made 12 tasks × 3 protocols × 3 repetitions, or 108 protocol runs per model. An independent qwen3.7-plus blind judge scored the outputs with a shared rubric. I also added deterministic acceptance checks for JSON structure, required fields, dates, arithmetic, and parts of the generated code.

“Independent” here means that Qwen did not generate the answers. It was still a model judge, not a human gold standard. A stronger study would need human blind ratings and a real-user experiment.

The most stable result: IDR is expensive, PPN sits in the middle

DeepSeek batch

• One-shot: 1,632 tokens on average, 13.41 seconds;
• PPN: 2,530 tokens, 19.55 seconds;
• IDR: 10,349 tokens, 47.30 seconds.

Kimi batch

• One-shot: 2,154 tokens on average, 9.81 seconds;
• PPN: 2,863 tokens, 12.40 seconds;
• IDR: 11,661 tokens, 34.76 seconds.

Across both models, PPN used roughly 75% fewer total tokens than IDR. It also reduced latency and repair overhead, although it still cost more than One-shot because the questions had to be asked and answered first.

This may be the most reliable conclusion from the current experiment:

If a task really needs clarification, asking focused questions before execution is usually cheaper than generating a result first and repairing it through multiple rounds. If the task is already clear, pre-task clarification is just extra overhead.

Because I did not have a verifiable per-request dollar rate, I did not force token usage into a dollar-cost estimate.

The quality results do not show that PPN is generally better

DeepSeek: One-shot was highest

The independent judge’s average quality scores were:

• One-shot: 88.50;
• IDR: 87.81;
• PPN: 84.58.

PPN scored 3.92 points below One-shot on average, but the bootstrap interval crossed zero, so the difference was not reliable statistical evidence. Composite success rates were 72.2% for PPN, 75.0% for One-shot, and 83.3% for IDR. IDR had one protocol-availability failure; the failed record was retained and included according to the pre-specified rule instead of being silently removed.

Kimi: PPN was descriptively higher, but still not significant

The Kimi batch produced these average quality scores:

• PPN: 73.31;
• IDR: 68.36;
• One-shot: 65.83.

This time the direction was reversed: PPN received the highest descriptive score. But the paired comparison between PPN and One-shot gave p=0.422, and the comparison with IDR gave p=0.570. Neither supports the claim that PPN has been proven better.

The cross-generator model × protocol interaction also did not provide reliable evidence. The models showed different descriptive patterns, but the current sample cannot establish that a particular model is especially suited to PPN.

Does PPN work better as tasks become more complex?

The current data does not justify that conclusion either. On the lower-complexity tasks, One-shot was often strongest. On some medium-complexity tasks, IDR received higher quality scores, but at a large token and latency cost. PPN did not consistently lead on highly ambiguous tasks.

The value of clarification probably depends on several factors:

• whether the missing information would actually change the result;
• whether the constraints are easy to misunderstand;
• how expensive a failed first attempt would be to repair;
• whether the user is willing to answer questions;
• whether the task can trigger an external side effect.

The deterministic checks did not change this conclusion. They can validate JSON, fields, dates, and arithmetic, but they cannot decide whether open-ended writing sounds natural or prove that a room’s structure is preserved in an image. Their correlation with the Qwen quality scores was approximately 0.466, so they are useful supporting evidence, not a replacement for human evaluation.

What product direction does this support?

The results do not support a mandatory “PPN for every request” workflow. They support an adaptive clarification layer that decides whether asking is worth the cost.

The policy could be understood in three broad cases:

• Simple, explicit, low risk: execute directly instead of asking questions for their own sake;
• A consequential ambiguity: ask only the high-value question that can change the result;
• Many constraints, multiple collaborators, or publication risk: confirm the critical parameters before execution and leave an auditable record.

The important product artifact is not a longer prompt. It is a structured Edit Contract or task contract that defines the goal, allowed changes, forbidden changes, and acceptance criteria.

A real-estate editor should preserve property facts

For real-estate images, I would rather build a property-preserving listing editor than a generic tool that simply makes pictures “look better.”

The default mode should be conservative:

• remove clutter and obvious distractions;
• improve exposure, white balance, shadows, and noise;
• correct lens distortion, perspective, and vertical lines;
• preserve the empty or furnished state of the room;
• do not automatically add furniture, plants, windows, doors, or change the layout.

The system may need to ask only a few questions:

1. Should the property remain empty, or is virtual staging allowed? 2. Which objects may be removed or added? 3. Does “make the view level” mean correcting perspective and vertical lines, or reconstructing a higher or lower camera angle?

The third question matters. Perspective correction is a relatively low-risk image transformation. Changing the camera height or inventing a new viewpoint can change the apparent facts of the property. Those operations should not be hidden behind the same phrase, “make it level.”

Multi-view listing images need another layer of constraints

Three images of the same room, taken from the left, center, and right, should not be treated as three unrelated images.

A better workflow would be:

1. identify that the images belong to the same room; 2. select one image as an anchor view; 3. build a room-level scene manifest for fixed fixtures, doors, windows, walls, floors, and existing objects; 4. apply the same allowed and forbidden changes across the three views; 5. run a cross-image consistency check after editing; 6. output before-and-after comparisons and a Change Log.

Exposure, white balance, denoising, cropping, and perspective correction should use deterministic image tools whenever possible rather than a free-form generative model. When generative editing is necessary, it should be paired with masks and an explicit list of things that must not change.

That is why “ask one question before generating” is not enough. Multi-image editing also needs scene-level state management and result validation.

Related work is already moving in this direction

This research is not the first attempt to make LLMs ask clarifying questions. Existing work has studied selective clarification, question generation, interactive intent acquisition, and help-seeking in agents. For example:

• FATA: First Ask Then Answer is close to an ask-before-answer interaction structure;
• AskBench studies when to ask, what to ask, and whether the system asks too much;
• CLAM studies selective clarification for ambiguous questions;
• Tell Me More / IN3 focuses on implicit-intent understanding before agent execution;
• Ask Early, Ask Late, Ask Right studies the value of clarification timing in long-horizon agents.

I therefore do not present PPN as a completely new clarification paradigm. More precisely, this study treats information timing as a reproducible protocol variable. Under matched tasks, facts, constraints, and acceptance criteria, it compares direct execution, batched pre-task clarification, and iterative repair while measuring quality, success rate, tokens, latency, repair burden, and protocol availability.

What has this study not shown?

The experiment has clear boundaries:

• only 12 synthetic tasks;
• only two generator models;
• quality was judged mainly by one model-based evaluator;
• no human blind rating yet;
• no real-user comparison between ordinary chat and an adaptive clarification layer;
• no completed real-estate image benchmark;
• text-protocol results cannot prove that a vision model preserves consistency across multiple views of a room.

The next stage needs two parallel tracks. One should compare ordinary chat with an adaptive clarification layer using real users, measuring completion rate, quality, total time, user input, clarification burden, repair, and abandonment. The other should build a listing-image benchmark for empty-room preservation, property-fact fidelity, cross-view consistency, and listing readiness.

The conclusion

When a task is already clear, One-shot is often the more sensible default. When a consequential ambiguity exists, asking before execution may be cheaper than repairing a failed attempt. PPN may be a useful middle option, but the current evidence does not show that it is uniformly better than direct execution or iterative repair.

For products, the more useful question is not “How do we make the model always ask first?” It is:

How do we make the system decide when asking is worth it, which question has the highest value, and when it should stop asking and start acting?

For real-estate images, that decision needs one additional boundary: the image can become cleaner and easier to present, but “looking better” must not turn into inventing a property that does not exist.