Whether a generated artefact is framed as a draft or a finished piece decides whether the UI should lean editor or viewer

What it is

The same report, locked in a read-only card, primary actions “copy / regenerate” — treated as finished. The same report lying in a typable document, primary action a caret — treated as a draft. Draft vs finished framing decides whether the UI should behave like an editor or a viewer. Frame it wrong, and people dare not edit when they should, or keep polishing wording when they should be accepting.

How hard takeover is, and whether regenerate will overwrite edits, all happen after this framing.

Why it happens

A UI schema names legal actions. A viewer’s legal actions are accept or fetch another; an editor’s is change. Generated artefacts are born ambiguous: sometimes a deliverable, sometimes material. The product has to pick a default schema. Pick viewer, and editing is demoted to “convert first”; pick editor, and acceptance is demoted to “decide for yourself when to stop.” People will not hold both schemas at once; the primary button reveals which one the product picked.

The default schema also shapes responsibility: a viewer implies “the system handed this over”; an editor implies “you are writing this.” Overwrite, attribution, and settling for less all follow that implication.

Studying it

The same artefact, viewer shell versus editor shell. Dependent variables: first action (copy, regenerate, edit in place), amount of change, whether the output is sent as already finished. Independent variables: primary button, editable by default, completion copy (“generated” vs “draft”).

First action is whether the framing was read. Self-report of “I think this is a draft” is weaker than what the first tap did.

Where it stops holding

Closed answers (a number, a violation or not) should be a viewer plus a check; an editor invites people to alter a correct result. Long co-edited prose should be an editor. Legal or medical output that must be signed should be a viewer that refuses direct send-out, forcing a signed edit. Crowded editor controls on a narrow screen are layout, not a reason to reframe as a viewer.

Applying it

• Write down whether this output is material or a deliverable in the task. Material: caret on open. Deliverable: accept on open; editing is an explicit enter.
• Primary button and copy must match the framing. Do not write “feel free to edit” on a viewer and bury edit in a menu.
• The two framings may switch, but switching is one explicit act; do not let the same region look like both a card and a document.
• Check: unprompted, watch the first effective action after generation. If the framing is draft and most people first copy-and-send, the UI is still a viewer.

Related

• Same group: L3.12.2 Regenerating after the user has taken over will overwrite human edits unless a merge rule is explicit · L3.12.3 Human edits should be marked, or afterwards no one can tell which stretch came from whom · L3.12.4 The higher the takeover threshold, the more people settle for a result they dislike · L3.12.5 Editing a generated artefact can take more skill than writing from scratch, because the existing text must be understood first
• Nearby: L3.13 User Feedback Loops on Generation Quality · L2.12 Iterative Edits and Local Regeneration
• Search terms: draft vs finished · editor versus viewer · artefact framing