A pasted screenshot's instruction is obeyed, but the assistant's draft still needs a confirm click — what does that constrain about which argument values survive?

## What a confirm click actually reviews In an assistant that drafts a reply or an invite and waits for the user to press send, the gate is a person looking at a rendering. It is not an audit of the structured call underneath. The rendering shows a subset of the fields, at a level of detail chosen for readability, to someone who already believes they know what they asked for, because they are the one who pasted the screenshot and said to deal with it. That belief is the second half of the obstacle: the first half was their glance at the picture, and the second is their skim of the draft. ### The two axes the construction is squeezed on **Axis one, the visible surface.** Whatever the preview foregrounds has to remain consistent with the task the user handed over. A draft that reads like an answer to the thing in the screenshot passes a skim; one whose visible body or subject has clearly drifted does not. **Axis two, where an unchosen value can sit.** Any argument the user never named has to occupy a field the rendering summarises, truncates or omits. Typical shapes are a recipient list rolled up behind a count, an additional calendar guest, a reply-to, an attachment reference, a thread the message lands on, or a time zone. None of these are exotic; they are simply the fields interface designers fold away because they are noisy in the common case. The two axes trade against each other. The more the payoff needs the visible part to change, the sooner a skim catches it, which is why the payoffs actually reachable through this obstacle are the unremarkable ones rather than the dramatic ones. ### What the record proves afterwards This matters more than the mechanics, because the argument that follows a finding like this is always about consent. An audit entry fixes which capability ran, with which argument values, and that an approval event was recorded. It does not record who chose each value. It cannot separate a value the user asked for, a value the model inferred from context, and a value that came from a sentence inside a picture, because by the time the call is formed they are all just fields. The origin turn shows a text part and an image part; the image's contribution to the arguments appears nowhere as such. So the direction of every claim has to be watched. The click proves an approval event occurred against a rendering. It does not prove the person read the fields, and it certainly does not prove they chose them. Treating the approval as consent to the arguments is the single most common way this class of finding gets closed as user error. ### Triaging it honestly A defensible write-up says: a span inside an image in the user's own turn produced a call whose visible surface matched the handed-over task, while one value the user never named sat in a field the preview did not render; the approval event that follows is therefore not evidence of intent for that value. It also states what was observed and how often, because the carrier depends on a crop and a rendering that the person building it does not control, and one success against one configuration is one observation. Calling it user error requires claiming a person declined to read something they were never shown, which does not survive contact with the record. ### Where it stops working * The payoff needs a field the preview foregrounds, so the skim has something to catch. * The task the user handed over is specific enough that any drift in the visible body reads as wrong. * The assistant does not hold a capability whose interesting arguments are foldable. * The picture never reaches the model, or the crop excluded the span, so there is no obeyed instruction to begin with. Each of these is a different reason for failure, and a report that does not separate them overstates what the construction is worth.