Draft output generation

Draft output generation is the execute-stage step where a language model writes a first version of the task deliverable from the brief and available source materials. The deliverable may be a customer reply, an internal status note, a short report, a handoff summary, or another document the queue expects. The model drafts. The operator still reviews, edits, and is the one who sends or files the final version.

The point of this step is speed of the first pass, not unsupervised publication. A usable draft removes blank-page time and pulls structure, tone, and cited facts into one editable artifact. It does not decide that the work is ready for the outside world. That decision stays with the human who owns the case.

When the task brief or the required source materials are missing, the correct output is empty: no invented paragraphs, no placeholder prose that looks finished, and no speculative fill for facts the system never received. An empty result is clearer for the operator than a confident draft built on guesswork.

Use draft generation after the case is scoped and the materials needed for that task type are available or explicitly marked as absent. In a healthy flow, procedure retrieval at task start has already surfaced the playbook, templates, and constraints that should shape the draft. Drafting too early, before the brief is clear or before sources are attached, produces fluent text that still fails review.

Typical fit:

• High-volume queues where many tickets share a known template shape (acknowledgments, status updates, standard exceptions).
• Tasks that need a full narrative first pass, then human judgment on tone, escalation, and what to leave out.
• Work where the operator already knows the decision, but typing the full deliverable is the bottleneck.

Poor fit:

• Tasks that are still in discovery, with no agreed ask or audience.
• Cases where the only safe action is a short system status or a hold message until data arrives.
• Situations that require a signed, regulated, or irreversible action the model must not initiate.

Treat draft generation as one execute step among several. Completeness and adversarial checks belong after a draft exists, not as a substitute for drafting. See automated completeness check and adversarial review pass for those later gates.

A draft is only as grounded as its inputs. At minimum, the step should receive:

1. Task brief. What must be produced, for whom, by when, and what “done” means for this ticket type.
2. Source materials. Case history, extracted facts, policy excerpts, prior decisions, and attachments the operator has approved as in-scope.
3. Procedure and template cues. Required sections, prohibited claims, tone rules, and channel limits retrieved for this task.
4. Explicit gaps. Fields or documents that are known missing, so the model can refuse to invent them.

If the brief is blank or the mandatory sources for that procedure are not present, return empty output and surface the gap to the operator. Do not soft-fail into a generic letter that “sounds right.” Operators reviewing first-draft deliverables waste less time when the system says “cannot draft: missing X” than when they must unwind invented detail.

When partial materials exist, prefer a partial draft only if the procedure allows it: for example, draft the sections that are fully supported and leave unsupported sections blank or clearly marked as blocked. Marking unsupported sections is an operator aid; inventing content for them is not.

The operator’s job after generation is editorial ownership, not rubber-stamping. A practical review pass usually covers:

• Ask match. Does the draft answer the actual request, or a neighboring one the model inferred?
• Fact check. Every concrete claim should map to source material or be removed.
• Procedure fit. Required sections, disclaimers, and escalation language should follow the retrieved playbook.
• Tone and channel. Customer-facing wording, internal jargon, and length limits differ by destination.
• Action safety. The draft must not promise outcomes, approve exceptions, or commit resources the operator has not confirmed.

Edit in place. Treat the model text as clay: keep structure that helps, rewrite anything that overreaches, and delete filler. Sending or filing is always a human action in this pattern. If your tooling auto-sends, that is a different control surface and outside the intent of draft-only generation.

Operators should also watch for over-completeness. Models often fill every section of a template even when the case only needs three lines. Shorter, accurate deliverables beat long drafts that bury the decision.

Common failure modes when reviewing first drafts:

• Hallucinated specifics. Dates, amounts, ticket IDs, or policy citations that never appeared in sources.
• Silent omission. Required fields left out while the prose still reads polished.
• Wrong template. A refund-style draft for a status-only ask, or an internal note voice on a customer channel.
• Premature certainty. Language that closes the case when the brief asked only for an interim update.
• Drafting on empty inputs. Fluent output when brief or sources were missing.

Empty-output rules to enforce at the step boundary:

• No brief → empty.
• Mandatory sources for the active procedure are missing → empty, with the missing items listed for the operator.
• Conflicting sources with no resolution rule → empty or a blocked draft that states the conflict without picking a side.
• Procedure forbids generative drafting for this task type → skip the step; do not call the model.

When a draft is produced, downstream checks should still run. An automated completeness check catches missing sections and required fields. An adversarial review pass pressure-tests weak claims, risky commitments, and tone failures before the operator finalizes. Those steps complement drafting; they do not authorize unsupervised send.

For queue owners and operators, keep draft generation boring and auditable:

• Log which brief version, sources, and procedure snapshot fed the draft.
• Store the model draft and the operator’s final version so edits remain reviewable.
• Prefer deterministic empty results over “best effort” prose when inputs fail validation.
• Measure time-to-first-editable-draft and edit distance, not vanity “auto-resolved” rates that hide human correction.
• Revisit prompts and templates when operators repeatedly delete the same invented sections.

Draft output generation earns its place when it shortens the path from assigned task to a reviewable artifact, while keeping authorship and release authority with the operator. The model accelerates the first write. The human remains accountable for what leaves the queue.