A playbook is not a list of tips. It is a set of named plays, each with a trigger that tells you when to run it, an owner accountable for the outcome, and a place in a sequence. For legal and compliance drafting, where the cost of an uncontrolled error is high, this structure is what turns a promising tool into a dependable operation.
This article lays out that playbook end to end. It covers the plays for intake, drafting, verification, approval, and continuous improvement, and it specifies the triggers and owners so the practice runs the same way regardless of who is at the keyboard. The plays are deliberately concrete; a playbook nobody can execute under deadline pressure is decoration.
Read this alongside the workflow and team-rollout pieces. The workflow gives you the linear process; this gives you the situational plays and the decision points where the process branches.
The Intake Plays
Everything starts with how a drafting request enters the system.
Play: Classify the task before drafting
Trigger: any new drafting request. Owner: the requesting drafter. Before touching a model, classify the task by stakes (internal versus external), document type, and jurisdiction. Classification routes the request to the right prompt and the right approval gate. Skipping it is how high-stakes work accidentally gets low-stakes handling.
Play: Assemble grounding material
Trigger: a classified task that references law, contract, or policy. Owner: the drafter. Gather the actual source text the draft must rest on and paste it into the prompt. The standing rule is that the model drafts from supplied material, never from memory. No grounding material, no drafting.
Play: Select the approved prompt
Trigger: grounding material in hand. Owner: the drafter, drawing from the library. Pull the approved, versioned prompt for this task type rather than improvising. If none exists, that is a trigger to escalate to a prompt owner, not to freelance.
The Drafting Plays
With intake done, the actual generation runs under constraints.
Play: Draft with explicit constraints
Trigger: approved prompt selected. Owner: the drafter. Run the prompt with its house-style preamble: citation format, required disclaimers, the instruction to flag assumptions, and the refuse-rather-than-guess rule. The constraints are not optional decoration; they are the difference between a defensible draft and a risky one.
Play: Force uncertainty into the open
Trigger: any draft produced. Owner: the drafter. Instruct the model to mark every assumption and every claim it could not ground. This converts invisible uncertainty into visible flags the reviewer can resolve, which is far safer than a fluent draft that hides its gaps.
Play: Branch on novelty
Trigger: a task with no approved prompt or an unfamiliar jurisdiction. Owner: a practice-area prompt owner. Novel work routes to an owner who either adapts an existing prompt or handles the task manually. The playbook explicitly does not let novelty get improvised by whoever happens to hold the request.
Play: Decompose complex documents
Trigger: a document complex enough that one generation would bundle several distinct decisions. Owner: the drafter. Split the work into ordered steps, extract, draft, verify, so each intermediate is inspectable rather than buried in one opaque output. This is the same logic detailed in The Definitive Guide to Decomposition Prompting for Hard Tasks, applied to regulated text where checkability is a control, not a convenience.
The Verification Plays
This is where most of the protective value lives.
Play: Run the verification checklist
Trigger: any draft headed toward use. Owner: the drafter, then the approver. Check every citation against a real source, every figure and date against the grounding material, and the modal force of every obligation. A draft cannot exit this play with any item unchecked.
Play: Compare simplifications to source
Trigger: any plain-language conversion. Owner: the drafter. Compare the simplified text against the original specifically for dropped qualifiers and conditions. Readability is not the thing being verified; fidelity is.
Play: Escalate caught fabrications
Trigger: verification catches an invented citation or a wrong figure. Owner: the drafter, logging to the prompt owner. Every caught error becomes a logged near-miss, which feeds the improvement plays. Catching an error and moving on without logging it wastes the most valuable signal you get.
The Approval and Release Plays
Nothing of consequence ships without a gate.
Play: Human approval for external documents
Trigger: any document headed to a client, regulator, court, or counterparty. Owner: a qualified human approver. The approver reviews and signs, taking ownership of every word. The model produced the draft; the human makes the representation.
Play: Capture provenance on release
Trigger: a document approved for release. Owner: the approver. Record the source material, the prompt, and the review. This is the audit trail that makes the practice defensible if anyone later asks how the document was produced.
Play: Hold the line on confidentiality
Trigger: any task involving privileged or confidential material. Owner: the drafter, with policy set by the function. Confirm the deployment's data handling permits the material before it is entered, and route anything outside the approved envelope to a manual process. This play runs as a precondition, not an afterthought, because a confidentiality breach cannot be undone once the material is submitted.
The Improvement Plays
A playbook that never updates decays.
Play: Review the library on a cadence
Trigger: a scheduled interval. Owner: prompt owners. Retire stale prompts, fold in near-miss lessons, and update preambles for new model behavior. The cadence keeps the plays current rather than letting them rot into liabilities.
Play: Re-validate after model updates
Trigger: the underlying model changes. Owner: prompt owners. Re-test critical prompts, because behavior drifts across versions and controls that are never re-tested degrade silently. The broader rollout context for these plays sits in Standardizing AI Drafting Across a Legal and Compliance Function, and the risks they defend against are catalogued in The Quiet Liabilities Buried in Prompting for Legal Text.
Play: Promote proven prompts into the library
Trigger: a drafter or owner produces a prompt that handles a recurring task well. Owner: the practice-area prompt owner. Review it, attach a house-style preamble, document its known failure modes, and add it to the versioned library as an approved entry. This is how the playbook grows from experience rather than freezing at launch, and it ensures that a good solution found once becomes reusable by everyone instead of staying in one person's notes.
Running the Plays Under Pressure
A playbook only matters if it survives a real deadline, so a few operating principles hold the plays together.
Make the safe path the fast path
If following the plays is slower than skipping them, people will skip them when it counts most. Keep the approved library well stocked and the verification checklist tight enough to run quickly, so the controlled path is also the convenient one. A playbook that only works when nobody is busy is not a working playbook.
Default to escalation, not improvisation
When a situation does not match a known play, the standing instruction is to escalate to an owner, never to invent a workaround under deadline. Improvisation is precisely where uncontrolled legal risk enters, so the playbook makes escalation the reflexive response to anything unfamiliar.
Frequently Asked Questions
How is a playbook different from a workflow?
A workflow is the linear process from request to released document. A playbook adds the situational plays and decision points, including how to branch on novelty or escalate a caught error. The two are complementary; the workflow piece covers the linear path in Making Legal Drafting With AI a Process Anyone Can Run.
Which play matters most if I can only adopt one?
The verification checklist play. It catches the errors that look correct and would otherwise survive into a signed document. Grounding prevents many errors upstream, but verification is the gate that protects what slips through.
Who owns the plays day to day?
Drafters own intake, drafting, and first-pass verification. Approvers own release and provenance. Practice-area prompt owners own novelty handling and improvement. Clear ownership per play is what keeps the system from defaulting to whoever is least busy.
What triggers an escalation rather than a draft?
An unfamiliar jurisdiction, a task with no approved prompt, or anything that constitutes advice outside someone's competence. These route to a prompt owner or qualified human rather than getting improvised under deadline.
How do caught errors improve the system?
Each caught fabrication or wrong figure is logged as a near-miss and fed into the cadence review, where it informs prompt updates. A team that logs and learns from near-misses tightens its plays continuously instead of repeating the same mistakes.
How often should the improvement plays run?
The library review should run on a fixed cadence regardless of model changes, and re-validation should run additionally whenever the underlying model updates. Both are scheduled, owned events, not things that happen when someone remembers.
Key Takeaways
- A playbook adds named plays, triggers, and owners on top of a linear workflow, which matters most where errors are costly.
- Intake plays classify and ground every task before any drafting begins.
- Drafting plays run under explicit constraints and force uncertainty into the open.
- The verification checklist is the highest-value play; no draft exits with an item unchecked.
- Human approval and provenance capture gate every consequential release.
- Improvement plays, run on a cadence and after model updates, keep the system from decaying.