If one draft sounds smoother, it is tempting to call it better. Compare both drafts against the same requirements before deciding which one you can use.
Write the requirements before reading the outputs
For a routine update, choose a small set of requirements: the status, the next step, the important uncertainty and the intended audience. Identify which facts come from the supplied source. Do not add a requirement only after seeing a weakness in the draft you dislike.
Keep the two drafts under neutral labels, A and B. Record the source and instructions used for each. If the instructions differ, say so; you are comparing two workflows, not isolating the effect of a single model change.
A fictional pair of drafts
Source note: “The export feature is ready for internal testing. Testing starts Tuesday. No customer release date has been agreed.” The reader is an internal colleague who needs to know the next step.
Draft A: “Our improved export feature launches Tuesday, giving customers a seamless experience.” It is compact, but it changes internal testing into a customer launch and invents a benefit.
Draft B: “The export feature is ready for internal testing, which starts Tuesday. A customer release date has not been agreed.” This keeps the supplied status, next step and uncertainty. It does not establish whether the software itself works; it only represents the note more accurately.
Use separate checks rather than a single impressive score
For the example, A fails accuracy and omits the uncertainty. B preserves the three supplied points. You can still improve B’s style, but polishing A first would spend time on a draft with the wrong meaning. A pass/fail note for each requirement is often clearer than adding arbitrary points into a total.
- Accuracy: does every important claim match the source?
- Completeness: are the required points and caveats present?
- Audience: does the reader have enough context to act?
- Editing effort: which changes would make the draft usable?
Record the rejected option too
Keep both drafts and the reason for your decision. If you later change instructions, the original failure helps you check whether the new version actually fixed it. Do not silently discard a poor result and claim every attempt worked.
Time corrections if your question is about effort. A draft that takes longer to generate but needs one small edit may be a better local choice than an instant draft that requires factual reconstruction. A single pair is an example, not a general performance result.
Make a limited decision
Write the outcome narrowly: “Use B for this internal update after checking the original note.” If several comparable tasks show the same problem, adjust the instructions or limit the assistant’s role. Keep a human responsible for the final communication.
The checklist helps you choose a usable draft. It does not certify a model, replace a subject expert or prove that the next response will have the same quality.
Use this next
Keep exploring
Use the free tools