If the output cannot be edited, the user can only accept it or start over

What it is

A generated mail sits in a read-only bubble. Eighty percent is right; one greeting is wrong. There is no entry to change that line, only Use this or Generate another. That is the accept-or-redo trap: the decision set is crushed into two extremes, and every in-between act — change a word, drop a sentence, swap a number — does not exist. The product looks like it offers control (you can retry). It offers lottery tickets.

This sits next to “retry-only is no control,” but the break here is the decision structure. The person is not doing continuous revision. They are passing a verdict on the whole artefact.

Why it happens

Read-only output treats the generation as a display, not as material. A display’s legal acts are take or discard. The next draw after discard re-samples the whole distribution; the eighty percent that was already right is not locked as a condition, so “again” often throws away the good parts too. People learn quickly: a near-miss is accepted, because the expected value of another draw is worse. Accepting-as-is sends the wrong greeting.

Copying into an external editor is an informal escape. Once that escape is the main path, the in-product Redo button is an admission that there is no middle grade.

Studying it

Give an artefact that is wrong at a single point and right elsewhere. Split the UI into read-only plus redo versus in-place edit of that point. Dependent variables: rate of accepting the wrong version, redo count, whether text is copied out, task time. Also ask “did I edit it” — the read-only group, even after many redos, often reports they never edited, because they never touched the text.

Control how visible the error is. Too loud and everyone will redo, and you will miss settling. Hide it in a greeting, a date, an attachment name, closer to the miss that happens before a real send.

Where it stops holding

If the output is a one-shot spectacle (a joke, a mood image) with no downstream use, two options are enough. If the output is about to enter an authoritative external editor (code into an IDE, prose into an existing doc tool), read-only is a transfer — provided copy is complete and formatting survives. High-stakes sends (outbound mail, a public notice) still need a check before send even when editable; editable does not automatically mean sendable.

Applying it

• Put the generation on a typeable surface by default: text is an editor, a slide is a clickable object, not a chat bubble.
• Keep Use this and Generate again if you want, but a third path must exist: change it on this copy. That path must finish without leaving the current view.
• Settling is observable: if the sent artefact matches the generation byte-for-byte, and the generation had an error the user dwelt on but did not change, log it as accept-or-redo settling.
• Check: plant a draft with one error. Under a read-only UI, count how often it goes out with the error; after making it typeable, the same error should be fixable without regenerating. If people still regenerate the whole piece, see whether the edit entry is buried in a menu — it has to sit next to the line that is wrong.

Related

• Same group: L2.13.2 After the user edits the result, later turns must respect those changes · L2.13.3 Too many control dimensions turn a generation tool into specialist software that has to be learned · L2.13.4 Different expertise needs different grain; grain should be switchable, not one size
• Nearby: L2.06 Granularity of Control · L3.12 Editing and Taking Over Generated Content · L2.12 Iterative Edits and Local Regeneration
• Search terms: accept-or-redo trap · read-only generation · all-or-nothing output