Legal Context-to-Draft Prompting Playbook: Source Packets, Preference Memory, Structured Memoranda, Citation Verification, and Lawyer Sign-Off

Why legal context-to-draft prompting needs a source-led playbook

OpenAI’s Harvey customer story describes a legal workflow pattern that many teams are trying to operationalize: combine matter-specific context, lawyer drafting preferences, and structured legal outputs so that attorneys can move from scattered materials toward a reviewable draft. OpenAI reports that Harvey uses GPT-6 Astra to help lawyers analyze, synthesize, and draft from court information, law-firm documents, case-law research, and other matter context. OpenAI also describes a Harvey memory panel that can bring individual preferences into the workflow, including examples such as numbered lists, prioritizing EDGAR as a source, and color-coding issues by priority. Those facts are useful as a pattern, but they do not give outside users Harvey’s product, controls, integrations, training, legal quality, customer environment, or professional-review process.

This playbook therefore does something narrower and more practical: it translates the documented pattern of matter context plus explicit lawyer preferences plus structured output into a conservative drafting workflow that a legal team can adapt inside its own approved systems. The goal is not to make ChatGPT, an API model, or any drafting assistant “practice law.” The goal is to make the prompt, the source packet, the draft, and the review trail easier for a qualified lawyer to inspect. In a legal setting, a polished paragraph is not the unit of trust; the unit of trust is a proposition tied to an authorized source, checked against jurisdiction, date, contrary authority, client instructions, confidentiality duties, and lawyer judgment.

OpenAI’s prompt engineering guidance recommends giving explicit instructions, structuring context, and testing prompts before production use. OpenAI’s safety best practices emphasize constrained inputs, human-in-the-loop review, and special care for high-stakes domains. Legal drafting is a high-stakes domain because a small error in authority, jurisdiction, filing posture, client facts, or privilege handling can change the risk profile of the work product. A useful legal prompt must therefore do more than ask, “Draft a memo.” It must specify which sources are authorized, which sources are controlling, what the jurisdiction and date boundaries are, what uncertainty must be flagged, which statements require pinpoint support, and what a human lawyer must approve before any client, court, counterparty, regulator, or public audience sees the result.

This opening section defines the operating vocabulary for the rest of the playbook. Later sections can build source packets, authority hierarchies, issue maps, proposition ledgers, citation checks, and sign-off workflows, but those tools are only safe if the team agrees up front on authorization, privilege, confidentiality, jurisdiction, currentness, source traceability, uncertainty, and qualified-lawyer sign-off. Those terms sound familiar, yet they are often the first things lost when a user pastes a long matter narrative into a model and asks for a “strong argument.” The playbook’s core discipline is to slow that moment down and force the draft to remain tethered to approved evidence.

This article provides 50 GPT-5.5 prompts for legal professionals covering contract analysis, compliance review, case research, and legal document drafting. The 50 GPT-5.5 Prompts for Legal Professionals: Contract Analysis, Compliance Review, Case Research, and Legal Document Drafting article is a focused companion for Evidence First Legal Drafting because it directly supports an evidence-first legal drafting section because it focuses on legal research, analysis, and drafting workflows rather than generic prompting.

The Harvey pattern: context, preferences, and structured legal output

The documented Harvey pattern is important because it describes the kind of inputs that make legal drafting assistants more useful to lawyers. OpenAI reports that Harvey uses court information, law-firm documents, case-law research, and other legal context. That list matters because legal drafting rarely begins from a blank page: it begins from pleadings, contracts, factual chronologies, discovery materials, client instructions, statutes, regulations, case law, agency guidance, transaction documents, correspondence, and internal work product. A legal model response that ignores the matter file may be fluent but useless; a response that overstates the matter file may be dangerous.

The second part of the pattern is lawyer preference. OpenAI gives examples of preferences that Harvey can bring into workflow: numbered lists, prioritizing EDGAR as a source, and color-coding issues by priority. These examples show that preference is not just cosmetic tone. A preference can encode how a lawyer wants issues sequenced, which source classes should be consulted first, what formatting makes supervisory review faster, and how risk should be surfaced. A securities lawyer might prefer EDGAR filings above press commentary when summarizing issuer disclosures. A litigation partner might prefer every section to begin with the rule, then application, then evidentiary gaps. A general counsel might want board-facing advice separated from litigation-risk analysis.

The third part is structured output. In legal drafting, structure is a control surface. A memorandum that separates “Facts,” “Questions Presented,” “Short Answer,” “Analysis,” “Adverse Authority,” “Open Questions,” and “Verification Ledger” is easier to challenge than a seamless essay. A table that pairs each proposition with a source, pinpoint citation, verification status, and reviewer initials creates friction against unsupported claims. A color-coded issue map can show priority, but it must not become a substitute for legal analysis. Structure should make review easier, not imply that the model has verified law or reached a professional conclusion.

This playbook borrows the pattern without claiming equivalence. It does not reproduce Harvey, its memory panel, its product controls, its user interface, its integrations, its security posture, its model behavior, or its legal quality. It also does not claim that GPT-6 Astra, ChatGPT, Codex, or any other OpenAI system will produce legally correct work merely because a prompt includes matter sources and preferences. The only safe claim is narrower: a source-led prompting process can help teams create drafts that are easier for lawyers to verify, revise, reject, or approve.

Operational boundary: Treat the model as a drafting and synthesis aid inside an approved workflow, not as an authority that can validate law, waive privilege, determine filing strategy, communicate with clients, or make legal commitments. All legal conclusions, external communications, submissions, filings, settlement positions, and strategy decisions require qualified-lawyer review and approval.

What this playbook is—and what it is not

This playbook is an operational drafting method for legal teams that already have permission to use an AI tool with the relevant material. It is designed for lawyers, legal operations teams, knowledge-management teams, legal technologists, compliance professionals, and advanced users who need a repeatable way to move from authorized source packets to reviewable drafts. It focuses on source manifests, authority hierarchy, matter chronology, issue mapping, preference profiles, modular drafting, proposition-to-source ledgers, quotation checks, citation verification, adverse-authority review, uncertainty registers, privilege screens, confidentiality review, redline comparison, supervisory sign-off, and post-matter learning.

This playbook is not legal advice. It does not tell a lawyer what law applies to a real matter, whether a filing should be made, whether a communication should be sent, whether a privilege has been preserved, whether a conflict exists, or whether a client should take a course of action. It does not authorize uploading confidential, privileged, sealed, personal, regulated, proprietary, or third-party material into any system. It does not override firm policy, court rules, client outside-counsel guidelines, protective orders, professional-conduct obligations, records-retention requirements, discovery obligations, data-processing agreements, or workspace administrator settings.

This playbook also does not assume that preference memory is appropriate for every legal workflow. A persistent preference can be helpful when it captures benign formatting or review habits, such as “use numbered lists” or “separate open questions from conclusions.” It can be risky if it stores matter-specific secrets, client identifiers, privileged strategy, health information, financial account data, or facts from one client that could influence another client’s work. A legal team should decide which preferences may be stored, which must be session-only, which must be matter-scoped, which must be redacted, and which should never be entered into an AI tool.

OpenAI’s account-security guidance recommends protecting accounts, using strong authentication practices, and responding quickly to suspicious account activity. For legal teams, account hygiene is not a side issue; it is part of confidentiality and privilege risk management. A source-led drafting process should be paired with approved accounts, workspace policies, access controls, session review, API-key hygiene where relevant, and clear instructions not to share credentials or use personal accounts for controlled legal material unless the organization has expressly approved that use.

This enterprise ChatGPT Work security checklist covers data governance, access control, and audit compliance for files and connected workflows, providing a practical control baseline when legal teams prepare prompts from confidential matter sources. The 3 Enterprise Security Checks Before Deploying ChatGPT Work — Data Governance, Access Control, and Audit Compliance article is a focused companion for Confidential Prompt Handling because the target addresses governed file access and audit controls, which is a stronger contextual fit for confidential prompt handling than a generic prompt-engineering guide.

The eight control definitions every legal prompt should carry

Before a legal team asks for a draft, it should define the controls that govern the prompt. These definitions can be placed in a reusable instruction block, a matter intake form, or a drafting checklist. The wording should be adapted by the responsible organization, but the concepts should not be skipped. When a model receives legal context without these boundaries, it may produce a plausible answer that is hard to audit because the answer does not reveal whether the source was authorized, current, controlling, complete, or uncertain.

Authorization: the first gate, not an afterthought

Authorization means the user has the right to use the material in the chosen workflow. In practice, authorization includes client consent or engagement scope where required, firm policy, confidentiality agreements, court orders, protective orders, employment obligations, vendor terms, workspace permissions, data-processing rules, and any limits imposed by the source system. A lawyer may possess a document but still be barred from entering it into a particular tool. A legal operations employee may have technical access to a repository but lack matter-level authorization to use its contents for drafting.

A conservative prompt should start by requiring the user to confirm that all sources are authorized for the intended use. It should also instruct the model to stop and ask for a source manifest if the user provides raw material without describing its authorization status. For example, a safe drafting instruction can say: “Use only the sources listed in the approved source packet. Do not rely on unspecified background knowledge for legal propositions. If a necessary source is missing, create an open-question entry rather than inventing the answer.” That instruction gives the model a narrower job and gives the reviewing lawyer a clearer audit path.

Privilege: protected material requires human judgment

Privilege is not a simple label that a model can validate. Whether a communication is privileged or work product can depend on who created it, why it was created, who received it, whether confidentiality was maintained, whether an exception applies, and which jurisdiction’s law governs. A legal prompt should never ask the model to decide that privilege has been preserved as a final matter. It may help organize a privilege-review checklist, but the privilege conclusion must remain with a qualified lawyer.

The safer workflow is to screen material before it enters the prompt. If privileged material is authorized for use in an approved environment, the source packet should mark it as privileged or work product, restrict who can access it, and limit whether text may be quoted in output. If privileged material is not necessary, use redacted summaries, synthetic facts, or source identifiers instead. The draft should include a privilege/confidentiality review checkpoint before any external communication or filing, because model-generated text can accidentally restate protected strategy in a form that looks like ordinary analysis.

Confidentiality: minimum necessary context beats maximal context

Legal users often assume that more context always improves output. In confidential matters, the better rule is minimum necessary context. Provide the model with the smallest set of approved facts, sources, and preferences needed for the drafting task. If the task is to outline a memorandum structure, the model may not need client names, transaction values, personal identifiers, sealed exhibits, full email threads, or internal settlement views. If the task is to compare two clauses, the model may not need the entire agreement or unrelated schedules.

Confidentiality also affects how examples should be created. Training a team with live client facts can normalize oversharing. A better training set uses public cases, synthetic facts, or heavily redacted documents that preserve the workflow without exposing sensitive content. When live matter material is necessary, the team should use approved systems, access controls, matter identifiers, and retention practices consistent with organizational policy. No prompt should request passwords, API keys, private keys, authentication codes, bank account details, unnecessary personal data, or other secrets.

Jurisdiction: the draft must know its legal universe

Jurisdiction is a drafting control because legal propositions can be correct in one forum and wrong in another. A federal district court decision, a state appellate case, an agency interpretation, a foreign statute, and a contractual governing-law clause do not have the same authority. A prompt that simply asks for “the law on enforceability” invites blended analysis. A better prompt states the court, governing law, procedural posture, date, and source hierarchy, then asks the model to separate controlling authority from persuasive authority and non-authority.

Jurisdiction should also be included in the output structure. A memorandum can include a short “Scope of law reviewed” section that states the jurisdiction, date range, source set, and exclusions. If the source packet contains authorities from multiple jurisdictions, the model should be instructed to tag each authority and avoid generalizing across them. If the jurisdiction is unknown, the model should produce a question list rather than a conclusion.

Currentness: legal and factual freshness must be verified

Currentness means the team has checked whether the law, rules, guidance, docket status, filing deadlines, contract versions, client facts, and factual record remain accurate as of a defined date. A model can help list what needs to be checked, but it should not be treated as a live legal update service unless the approved workflow includes current retrieval and verification. Even then, a lawyer must verify consequential authorities and deadlines against authoritative sources.

A useful prompt asks for “last verified” fields next to legal authorities and factual propositions. For example, a citation ledger can include columns for authority name, jurisdiction, proposition supported, source location, last checked date, verifier, and currentness concern. If a case has been superseded, distinguished, appealed, questioned, or affected by statute, the draft must surface that issue. If the model cannot determine currentness from the provided source packet, it should mark the item as unverified rather than smoothing over the gap.

Source traceability: every important proposition needs a path back

Source traceability is the antidote to fluent hallucination. The model should not merely produce an elegant memorandum; it should expose the evidentiary skeleton of the memorandum. Each factual proposition should trace to a document, paragraph, exhibit, transcript page, spreadsheet row, deposition page, docket entry, client instruction, or lawyer note. Each legal proposition should trace to a statute, rule, regulation, case, agency material, contract clause, or verified research note. If the source cannot be identified, the proposition should not be presented as established.

Traceability can be implemented with inline bracketed source references, footnote placeholders, a proposition ledger, or a separate verification table. The key is that a reviewer can move from the draft to the original source without guessing. A model-generated citation that looks plausible is not enough. The team should verify the authority exists, the quotation is exact, the pinpoint location is correct, the cited proposition matches the holding or rule, and the authority remains good or usable for the intended purpose.

Uncertainty: gaps should be visible, not hidden

Uncertainty is not a defect in legal drafting; hidden uncertainty is the defect. A well-controlled prompt asks the model to identify missing facts, conflicting records, unclear client instructions, ambiguous legal standards, missing controlling authority, adverse authority, and assumptions that require lawyer approval. This is especially important when a source packet contains partial records. If the model receives a complaint but not the answer, a contract but not all amendments, or a case excerpt but not the full opinion, it should flag the incompleteness.

The best uncertainty registers are specific. “Need more research” is too vague. A useful entry says: “No controlling authority in the source packet on whether the contractual notice provision is a condition precedent under the selected governing law; verify before asserting waiver argument.” Another useful entry says: “Client chronology states notice was sent on March 4, but email exhibit shows March 5 timestamp; resolve before finalizing limitations analysis.” Specific uncertainty gives the lawyer a task list rather than a general warning.

Qualified-lawyer sign-off: the final control remains human

Qualified-lawyer sign-off means a lawyer with appropriate competence, authority, and responsibility reviews the sources, analysis, drafting choices, professional obligations, and intended use before the output has any legal effect. The reviewing lawyer must be able to accept, reject, revise, or escalate the model output. Sign-off is not a checkbox placed at the end of an automated pipeline; it is the professional act that determines whether the draft can become advice, a filing, a client communication, a negotiation position, or an internal legal recommendation.

The sign-off requirement should be written directly into prompts and workflows. A draft can include a “Not approved for external use” banner until review is complete. A memorandum can include a reviewer block with source verification, citation verification, privilege review, confidentiality review, conflict check, jurisdiction check, currentness check, adverse-authority check, and final approval. If the matter involves a court, regulator, client commitment, payment, settlement, public statement, employment decision, health issue, safety issue, or other consequential action, human approval is mandatory before action.

A controlled opening prompt for legal drafting workflows

The safest first prompt in a legal drafting workflow is not a drafting prompt. It is an intake and control prompt that forces the user and the system to define the source packet, the boundaries, and the review obligations. This prompt should be adapted by the organization’s lawyers and administrators before use. It should not be used to upload confidential material unless the team has confirmed authorization and required controls.

Sample prompt: legal drafting intake and control gate

You are assisting with a legal drafting workflow inside an approved environment.
Do not provide final legal advice, file anything, send anything, contact anyone,
or take any consequential action. Produce only review materials for a qualified lawyer.

Before drafting, create a control summary using only the information I provide.

1. Authorization:
   - List the source categories I have identified as authorized.
   - Flag any source category that is missing authorization status.
   - Do not use or request secrets, credentials, unnecessary personal data,
     sealed material, privileged material, confidential material, or regulated data
     unless I confirm that use is authorized and protected by the required controls.

2. Matter scope:
   - State the client or matter identifier only if provided in an approved form.
   - State the jurisdiction, governing law, forum, agency, or contract regime.
   - State the procedural or transaction posture.
   - State the date boundary for legal and factual currentness.

3. Source packet:
   - Create a source manifest with source name, type, date, owner, authorization status,
     confidentiality/privilege status if provided, and intended use.
   - Separate facts, law, procedural materials, client instructions, and lawyer notes.
   - Do not infer missing source contents.

4. Drafting preferences:
   - List approved preferences, such as numbered sections, EDGAR priority,
     issue-priority coding, tone, audience, or memorandum structure.
   - Flag any preference that could conflict with accuracy, confidentiality, or professional duties.

5. Output controls:
   - For any later draft, require proposition-to-source traceability.
   - Require citation and quotation verification.
   - Require adverse-authority and currentness checks.
   - Require uncertainty flags and open questions.
   - Mark the output as not approved for external use until qualified-lawyer sign-off.

If any required boundary is missing, ask targeted questions instead of drafting.

This control prompt reflects OpenAI’s general prompt-engineering principle that instructions should be explicit and context should be structured. It also reflects OpenAI’s safety guidance that higher-stakes work benefits from constrained inputs and human review. The prompt does not guarantee correctness. Its value is procedural: it makes the model ask for the legal universe, authorized sources, preferences, and review gates before generating persuasive prose.

The first decision rule: no source packet, no legal draft

The central rule of this playbook is simple: no source packet, no legal draft. A source packet is the approved collection of materials the model may use for a defined task. It may include public authorities, firm research memoranda, pleadings, contracts, discovery excerpts, correspondence, transaction documents, client-approved facts, or lawyer notes, but only if the user is authorized to use them in the chosen system. The packet should also state what is excluded. Exclusions are important because they stop the model from appearing to rely on materials the lawyer has not reviewed or approved.

A source packet should not be a miscellaneous upload folder. It should be a manifest with source names, dates, versions, confidentiality status, privilege status, jurisdiction relevance, authority level, and intended use. For example, a litigation packet might separate the complaint, answer, motion papers, selected exhibits, deposition excerpts, docket entries, controlling statutes, controlling cases, persuasive cases, and internal attorney notes. A transactional packet might separate the signed agreement, drafts, schedules, amendments, board materials, regulatory guidance, disclosure documents, and negotiation notes. Each item should have a reason for inclusion.

The source packet should also include an authority hierarchy. A model should know whether to prioritize statutes over agency guidance, controlling appellate precedent over trial orders, contract text over negotiation summaries, signed documents over drafts, and EDGAR filings over media reports where that preference has been approved and is relevant. OpenAI’s Harvey story gives “prioritizing EDGAR as a source” as an example preference, but a legal team should define when that preference applies. EDGAR may be highly relevant for public-company disclosures, but it is not a universal legal authority and should not displace controlling law.

A useful source-packet rule is to force every draft section to identify its source basis. A “Facts” section should not include facts that are not in the packet. An “Analysis” section should not cite authorities that are not in the packet unless the workflow permits additional research and marks the new authority as requiring verification. A “Recommendation” section should be withheld or framed as a lawyer-review placeholder unless a qualified lawyer has supplied the strategic direction. The model can propose organization, questions, and draft language; it should not silently expand the record.

The second decision rule: preferences are instructions, not truth

Preferences help make outputs usable, but they can also introduce bias or false confidence. A preference for numbered lists can improve readability. A preference for color-coding issues by priority can speed triage. A preference for EDGAR can improve source discipline in securities-related drafting. But none of these preferences proves that the analysis is correct. The reviewing lawyer must still check the law, facts, source hierarchy, currentness, contrary authority, client goals, and professional obligations.

Preference profiles should be categorized. Formatting preferences include numbered headings, tables, executive summaries, defined-term conventions, and citation style placeholders. Source preferences include approved source hierarchies, preferred primary sources, and disfavored sources. Risk preferences include issue-priority labels, confidence labels, uncertainty registers, and escalation triggers. Audience preferences include court-facing, board-facing, client-facing, internal research, negotiation, or regulator-facing format. Each category should be reviewed for confidentiality risk and matter fit.

Persistent preferences should be kept generic unless the organization has approved a more specific memory design. A safe persistent preference might say, “Use numbered lists for issue summaries.” A risky persistent preference might say, “Always argue that Client X’s former executive lacked authority because of the internal investigation described in Matter Y.” The first helps format future work. The second embeds sensitive matter strategy and could contaminate unrelated work. Matter-specific preferences should generally stay inside the matter workspace, matter prompt, or source packet rather than becoming a general user memory.

A preference profile should also include an override rule. If a preference conflicts with accuracy, source traceability, privilege, confidentiality, jurisdiction limits, currentness, or professional responsibility, the model should flag the conflict and follow the legal control rather than the style preference. For example, if the user prefers a confident tone but the source packet lacks controlling authority, the output should say the point is unverified or uncertain. A prompt that rewards confidence over traceability is poorly suited for legal drafting.

The third decision rule: structured memoranda must include verification space

A structured memorandum should not merely imitate legal formatting. It should reserve space for verification. A conventional structure might include question presented, short answer, facts, governing law, analysis, conclusion, and next steps. A source-led structure adds source manifest, authority hierarchy, jurisdiction/date scope, proposition ledger, adverse-authority check, quotation verification, citation verification, privilege/confidentiality screen, uncertainty register, and lawyer sign-off block. Those additions make the memorandum less elegant but more reviewable.

The “Short Answer” section should be treated carefully. A model-generated short answer can appear decisive before the legal work is complete. For early drafts, use labels such as “Preliminary draft for lawyer review” or “Working analysis based only on provided sources.” The short answer should include uncertainty if the law or facts are incomplete. For example: “Based only on the provided contract and two cited state cases, the stronger argument appears to be X, but the packet does not include current citator treatment, contrary authority, or the full amendment history.” That phrasing helps prevent premature reliance.

The “Facts” section should distinguish source-supported facts from assumptions, allegations, disputed facts, and lawyer-supplied hypotheticals. A complaint allegation is not the same as an admitted fact. A client interview note is not the same as a signed declaration. A negotiation position is not the same as contract text. The prompt should ask the model to label factual status so that the lawyer can avoid converting allegations into facts or internal theories into record evidence.

The “Analysis” section should tie each legal proposition to authority. If a proposition lacks authority, it should be moved to an open issue or research task. If a case is cited, the draft should include the jurisdiction, court level, year, relevant holding or rule, pinpoint location if available, and verification status. If the draft uses a quotation, the quotation must be checked against the original source by a human or an approved verification workflow. The model should be instructed not to invent quotations, citations, docket numbers, statutory text, or parentheticals.

The practical risk: fluent drafts can hide weak evidence

The main operational risk in legal context-to-draft prompting is not that the model writes badly. The risk is that it writes well while hiding weak evidence. A fluent draft can merge disputed facts, persuasive authority, outdated rules, incomplete research, and strategic assumptions into a single confident narrative. That is why this playbook treats drafting as the middle of the workflow, not the end. Intake controls come first; verification and lawyer sign-off come after.

Legal teams should be especially cautious when the user’s prompt asks for advocacy. “

Build the source packet before asking for a draft

A legal context-to-draft workflow should begin with a source packet, not with a blank prompt that asks for a memorandum, brief section, contract clause, or client update. OpenAI reports that Harvey uses court information, law-firm documents, case-law research, and other legal context, and that the workflow can bring individual drafting preferences into the task. This playbook uses that documented pattern as inspiration only; it does not claim to reproduce Harvey, its product controls, its security posture, or its legal quality. The practical rule is narrower and safer: identify authorized sources, rank them by authority, separate facts from law, encode lawyer preferences, and require source-level verification before any human relies on the output.

The source packet is a manifest, not merely a folder of PDFs. It should state what each source is, who authorized its use, what issue it supports, its date and jurisdiction, any confidentiality or privilege constraints, and whether the source may be quoted, summarized, or used only as background. OpenAI’s prompt engineering guidance emphasizes explicit instructions and structured context, while OpenAI’s safety guidance emphasizes human-in-the-loop review for high-stakes uses. Legal drafting combines both concerns: the model needs organized context to produce useful structure, and the legal team needs a visible control layer so that no draft silently depends on stale, unauthorized, privileged, or unverified material.

Use this section as a working design for the “source packet and preferences” phase of the playbook. It is deliberately operational: it tells an associate, knowledge lawyer, litigation support analyst, legal operations manager, or AI governance lead what to collect, what to exclude, what to label, and what to make the model say when evidence is missing. It is educational content, not legal advice, and every legal conclusion, filing, communication, or strategy decision must remain subject to qualified lawyer review.

Source packet manifest: the controlled inventory

The manifest should be readable by a lawyer before it is used by a model. If the human reviewer cannot determine whether a document is authoritative, current, confidential, or relevant, the model should not be asked to rely on it. A source packet can be maintained in a document management system, e-discovery platform, research folder, secure workspace, or matter-specific spreadsheet, but the controlling prompt should summarize the manifest rather than dump an uncontrolled mass of files into the model.

This article explains how to build source-linked institutional memory for ChatGPT and Codex using entity resolution, citation graphs, RAG fallback, and freshness controls. The Build Source-Linked Institutional Memory for ChatGPT and Codex: Entity Resolution, Citation Graphs, RAG Fallback, and Freshness Controls article is a focused companion for Document Source Hierarchy because a document source hierarchy depends on tracing claims back to approved materials, which matches the target’s focus on source-linked memory and citation graphs.

Court information: docket posture, orders, filings, and procedural boundaries

Court information should be handled as a distinct source class because procedural posture can control the usefulness of every other source. A memorandum about a motion to dismiss, a summary judgment record, an injunction hearing, or an appeal depends on what has actually been filed, ordered, admitted, preserved, waived, or appealed. The source packet should identify the court, docket number if authorized for internal use, presiding judge or panel when relevant, operative pleadings, pending motions, scheduling orders, key transcript excerpts, and any sealed or restricted materials that must not be exposed to the model unless specifically authorized and protected.

The prompt should instruct the model to treat court information as procedural context, not as a license to infer facts beyond the record. For example, a complaint may allege facts, an answer may deny or admit them, a declaration may create evidentiary support, and a court order may determine a legal issue. A draft that collapses those categories can misstate the record. A safe instruction is: “Label allegations, admissions, evidence, procedural rulings, and holdings separately, and do not convert allegations into established facts unless the source packet identifies them as admitted or found by the court.”

For litigation teams, the manifest should also flag filing deadlines, hearing dates, page limits, local rules, standing orders, and formatting requirements as operational constraints rather than legal merits authorities. Those items can help structure a draft, but they require human confirmation before filing. No AI-assisted workflow should file, submit, send, sign, or serve anything; a qualified lawyer must approve the final content, procedural posture, and filing mechanics.

Firm documents: prior work product, templates, policies, and knowledge assets

Firm documents can improve consistency, but they are not automatically correct, current, or appropriate for a new matter. The source packet should distinguish between approved templates, prior briefs, internal research memoranda, clause libraries, practice notes, client-specific playbooks, risk matrices, and style guides. Each category needs a use rule. A prior brief may provide argument structure but may contain facts, authorities, strategy, confidential details, or positions that do not transfer. A template may provide headings and defined-term conventions but may need jurisdictional, factual, and commercial adaptation.

When using firm documents, the manifest should include the responsible practice group, last review date, matter type, jurisdictional assumptions, and any known limitations. A template marked “last reviewed 2022” should trigger a currentness warning before the model adopts its legal propositions. A research memo written for one client should not be reused for another client unless privilege, confidentiality, conflicts, and reuse permissions have been reviewed under firm policy. OpenAI’s safety best-practices guidance supports constrained inputs and human review in high-stakes workflows; in this setting, that means the firm should constrain the model to approved sources and require lawyers to approve any reuse of internal knowledge assets.

A practical instruction for firm documents is: “Use firm templates for organization and drafting style only unless the manifest marks a legal proposition as current and verified. If a prior work product source contains matter-specific facts, do not import those facts into the new draft. If reuse permission is unclear, flag the document as excluded and ask for lawyer review.” This prevents the model from treating internal history as universal authority.

Case-law research: authorities, treatment, and currentness

Case-law research requires a higher verification burden than general background context because legal authority can be reversed, distinguished, superseded, limited, criticized, or irrelevant outside its jurisdiction. The source packet should include the case name, court, date, jurisdiction, proposition supported, pinpoint location if available, treatment status as checked by an authorized research system or qualified reviewer, and the date on which the treatment was checked. The model should be instructed not to invent citations, holdings, quotations, parentheticals, docket numbers, or subsequent history.

A useful case-law entry should connect each authority to a proposition rather than merely listing cases. For example, “CASE-012 supports the proposition that a plaintiff must plead particularized facts showing demand futility under the applicable Delaware standard; use only if the supervising lawyer confirms the current standard and the cited pinpoint.” This is more useful than “CASE-012: demand futility case,” because it lets the model build a proposition-to-source map while forcing the lawyer to verify the proposition and currentness.

Adverse and contrary authority must be included, not hidden. A source packet that includes only favorable cases invites a misleading draft. The issue map should mark favorable, adverse, distinguishing, and background authorities so the model can produce a balanced analysis or a candid risk section. The lawyer can then decide the strategic treatment. The model should not decide that an adverse case is immaterial unless the supervising lawyer has provided that instruction and the reasoning is documented.

Client-approved facts: separating evidence from instructions

Client-approved facts should be limited to facts the legal team is authorized to use for the defined drafting purpose. A client interview note, email thread, board presentation, investigation timeline, spreadsheet, or business narrative may contain confidential or privileged material, personal information, trade secrets, health information, employee information, financial data, or settlement-sensitive content. The manifest should identify which facts are approved for the AI-assisted draft, which must be redacted, which may be summarized, and which should be excluded entirely.

Client-approved does not mean legally established. The draft should label a fact as “client-reported,” “document-supported,” “admitted,” “disputed,” “court-found,” or “unknown,” depending on the record. If the model is asked to write a factual background section, the prompt should require the output to preserve these labels. For example: “Do not state disputed client-reported facts as uncontested. Where a fact is material and supported only by client narrative, add a verification note and identify the source ID.”

For transactional work, client-approved facts can include commercial objectives, negotiation history, material terms, risk tolerance, board approvals, regulatory assumptions, and deal chronology. For litigation, they can include witness timelines, document-authenticated events, admissions, pleadings, and court findings. In both settings, the legal team should apply minimum-necessary principles: include only the facts needed for the draft objective, use redactions where possible, and never expose secrets, credentials, private keys, account numbers, unnecessary personal identifiers, or unrelated sensitive material.

Other authorized matter context: business, regulatory, technical, and procedural material

“Other matter context” is useful but risky because it can blur the line between background and authority. It may include public company filings, agency guidance, contract exhibits, technical documentation, expert reports, market materials, policy manuals, insurance documents, board minutes, press releases, or public statements. The manifest should label whether the source is legal authority, evidentiary support, business context, technical explanation, or drafting constraint. The model should be told what role each context source may play.

For securities, finance, or corporate-governance matters, an EDGAR preference can be a concrete drafting instruction: when public-company information is needed and EDGAR materials are authorized, prioritize the relevant public filing over secondary summaries. This follows the documented preference example from OpenAI’s Harvey story, where preferences can include prioritizing EDGAR as a source. The preference does not mean EDGAR answers every question, and it does not remove the need for lawyer verification of filing date, issuer identity, exhibit status, incorporation by reference, and the specific proposition being cited.

For technical or expert-heavy matters, the manifest should prevent the model from turning technical background into legal conclusions. A patent, cybersecurity, medical-device, construction, environmental, or financial-instrument matter may require expert interpretation. The prompt should state: “Use technical sources to describe the provided record at a high level. Do not infer expert opinions, causation, standard-of-care conclusions, damages, liability, regulatory compliance, or scientific validity unless those conclusions are expressly stated in an authorized source and marked as approved for use.”

Define the authority hierarchy before the model ranks sources

The authority hierarchy tells the drafting system which sources control, which sources persuade, which sources merely inform, and which sources are excluded. Without this hierarchy, a fluent draft may give equal weight to a court order, a client email, an internal memo, a blog post, and a stale template. OpenAI’s prompt engineering guidance supports explicit, structured instructions; in legal work, authority hierarchy is one of the most important explicit instructions because it prevents the model from smoothing over legal weight.

A hierarchy should be matter-specific. A federal securities memorandum may rank statutes, rules, SEC releases, EDGAR filings, controlling circuit authority, district court cases, and secondary materials differently from a Delaware fiduciary-duty memo or a commercial contract redline. The hierarchy should also account for forum, procedural posture, and requested output. A litigation brief requires a different authority presentation than an internal risk memo, a board update, or a client-facing issue list.

1. Controlling legal authority. Identify statutes, regulations, rules, binding appellate decisions, controlling court orders, and governing contract provisions that apply to the matter. Require jurisdiction and currentness checks before relying on them.
2. Case-specific procedural record. Identify pleadings, orders, transcripts, exhibits, admissions, stipulations, discovery responses, and docket entries that define what may be asserted in the matter.
3. Verified factual record. Identify documents, declarations, authenticated communications, approved chronologies, and client-approved facts that support factual statements.
4. Persuasive authority. Identify non-binding cases, agency guidance, treatises, practice guides, or analogous authorities, and require the draft to label them as persuasive rather than controlling.
5. Firm knowledge assets. Identify templates, prior work product, playbooks, and internal research as style, structure, or background unless marked current and verified for the legal proposition.
6. Business and technical context. Identify materials that help explain the transaction, product, market, system, or operational setting, while prohibiting unsupported legal conclusions from that context.
7. Excluded material. Identify documents that the model must not use, including unauthorized confidential material, unrelated privileged content, stale drafts, superseded research, or materials outside the approved scope.

The hierarchy should include a conflict rule. If two sources disagree, the model should not silently choose the more convenient one. The prompt should require a conflict note that identifies the source IDs, describes the inconsistency, and asks for lawyer resolution. For example, if a client-approved chronology conflicts with a filed pleading, the model should not harmonize the dates unless the packet provides an authorized reconciliation. If a firm template conflicts with a recent controlling decision, the draft should follow the verified current authority or flag the issue for a lawyer.

Matter chronology: facts need time, source, and status

A chronology is not a narrative; it is a controlled evidence table. Each entry should include date, event, source ID, fact status, issue relevance, and verification status. This matters because a legal draft often fails when it rearranges dates, treats a disputed event as admitted, or omits the temporal relationship between notice, breach, reliance, causation, loss, filing, or limitations. The model can help turn a verified chronology into prose, but it should not invent missing dates or fill gaps from context.

A safe chronology prompt says: “Build the factual background only from the chronology and cited source IDs. Preserve disputed, alleged, admitted, and court-found labels. If a date, sequence, source, or verification status is missing, insert an uncertainty note rather than inferring the missing information.” This instruction is simple, but it prevents one of the most common AI-assisted drafting failures: confident narrative continuity where the record is incomplete.

Issue map: connect questions, sources, and draft modules

The issue map turns the source packet into a drafting plan. It should identify each legal or factual issue, the governing jurisdiction, controlling sources, favorable authorities, adverse authorities, factual dependencies, open questions, and the intended draft module. The issue map is also the right place to use priority coding, because not every issue deserves equal space in the first draft. OpenAI’s Harvey story gives color-coding issues by priority as an example of individual preference support; this playbook converts that idea into a conservative, auditable coding scheme.

The issue map should include an adverse-authority field even when the team believes no adverse authority exists. The correct entry is not silence; it is “not yet checked,” “checked through date by reviewer,” or “known adverse authority listed.” This is important because a model cannot prove the absence of authority by drafting confidently. The legal team must use authorized research systems and lawyer judgment to verify adverse authority and currentness.

Source freshness: define the date boundaries of trust

Freshness controls should appear in both the manifest and the prompt. A source may be authoritative but stale, current but non-binding, or recent but unverified. For legal authorities, freshness means the authority has not been superseded, reversed, abrogated, amended, or limited in a way that affects the proposition. For facts, freshness means the record reflects the current procedural posture, client instructions, transaction status, or business condition. For firm documents, freshness means the relevant practice group or responsible lawyer has approved the template or memo for the current use.

The packet should include a “freshness cutoff” for each source class. For example: case-law treatment checked as of a specific date; docket reviewed as of a specific time and date; EDGAR filing pulled from a specified filing date; client factual approval received on a specified date; internal template reviewed on a specified date. The model should be instructed to display those cutoffs in a verification section instead of implying that all sources are current today.

Sample prompt language — source freshness

Use only sources listed in the manifest. For each legal proposition, identify the source ID and the freshness date provided. Do not state or imply that an authority is current beyond the manifest's checked-through date. If currentness is missing, stale, or unclear, write "Currentness not verified" and place the proposition in the uncertainty register for lawyer review.

This instruction is especially important for fast-moving areas of law, active dockets, regulatory guidance, emergency orders, sanctions, privacy rules, securities filings, employment rules, and litigation with frequent amended pleadings. A model-assisted draft can organize the work, but it cannot replace a lawyer’s obligation to verify current law and current facts before relying on the result.

Exclusions: tell the model what not to use

An exclusions list is as important as the source list. Legal teams often focus on what they want the model to consider, but high-risk errors often come from material that should not have entered the workflow: unauthorized confidential documents, unrelated privileged work product, superseded drafts, old research, settlement communications, sealed filings, personal information, sensitive HR files, medical details, or technical credentials. The exclusions list should be explicit, matter-specific, and visible in the opening prompt.

Exclusions should be framed as operational commands, not soft preferences. For example: “Do not use EX-001 through EX-009. Do not infer from their file names. Do not summarize them. Do not quote them. If an excluded source appears necessary, stop and request lawyer authorization.” This prevents a model from treating excluded materials as background context or using their metadata to fill gaps. It also gives the reviewer a clean audit point: if the output contains excluded material, the draft fails review.

• Unauthorized sources: documents not approved for AI-assisted processing or outside the matter scope.
• Privilege-sensitive sources: attorney-client communications, work product, investigation materials, or strategy notes requiring specific approval and controls.
• Confidential third-party sources: customer, counterparty, employee, vendor, or business materials not authorized for the drafting workflow.
• Superseded sources: old pleadings, expired term sheets, outdated research memos, prior versions of contracts, or withdrawn filings.
• Regulated or sensitive material: health, financial, youth, employment, biometric, location, or other sensitive data not necessary for the draft objective.
• Security material: passwords, API keys, private keys, tokens, recovery codes, account numbers, or system credentials, which should not be included in prompts or outputs.

OpenAI’s account-security guidance separately emphasizes protecting accounts and credentials. In a legal drafting workflow, that translates into a simple packet rule: never include credentials, tokens, private keys, passwords, or unnecessary account-security details in the source packet, and revoke or rotate exposed credentials through approved security procedures if accidental disclosure occurs. The drafting system does not need secrets to write a legal memorandum.

Create a preference profile that improves format without changing truth

Preferences should control presentation, structure, and workflow behavior; they should not override sources, authority, legal ethics, confidentiality, or lawyer judgment. OpenAI reports that Harvey’s memory panel can bring individual preferences into the workflow, with examples including numbered lists, prioritizing EDGAR as a source, and color-coding issues by priority. This playbook treats those examples as preference categories that legal teams can encode in a matter-specific profile. The profile should be approved by the responsible lawyer and should be visible in the prompt so reviewers can tell whether the model followed it.

A preference profile is not a memory dump of everything a lawyer likes. It should be short, auditable, and designed to reduce avoidable revision cycles. The best profile answers practical questions: Should the draft use numbered lists? Should issue priority be displayed? Should EDGAR filings be preferred for public-company facts? Should defined terms follow a house style? Should the tone be neutral, advocacy-oriented, board-ready, court-ready, or internal-risk-focused? Should the output include a proposition-to-source ledger and uncertainty register? Those decisions can be encoded without asking the model to make legal judgments on its own.

Preference profile template

Preference profile — matter-specific drafting controls

1. Numbered structure:
   Use numbered headings and numbered paragraphs for analysis sections unless the output type requires a different format.

2. Authority presentation:
   Separate controlling authority, persuasive authority, factual record, firm template material, and business context.

3. EDGAR preference:
   For authorized public-company facts, prioritize cited EDGAR filings over secondary summaries. Identify filing type, filing date, exhibit if applicable, and source ID. Do not infer securities-law conclusions from the filing without lawyer-approved authority.

4. Issue-priority coding:
   Use P1 / Red for outcome-critical issues, P2 / Amber for important supporting issues, P3 / Green for background issues, and PX / Gray for excluded or unresolved items.

5. Tone:
   Use a neutral, lawyer-review-ready tone. Do not overstate confidence. Do not use marketing language, dramatic phrasing, or unsupported certainty.

6. Defined terms:
   Preserve lawyer-approved defined terms exactly. If a defined term is missing, propose one in brackets and flag it for review.

7. Output structure:
   Produce: executive summary; issue map; facts relied upon; analysis by issue; adverse authority and counterarguments; uncertainty register; proposition-to-source ledger; verification checklist; lawyer sign-off items.

8. Confidentiality and privilege:
   Do not include confidential or privileged material in external-facing text unless the manifest marks it as approved for that use. Flag any source-use ambiguity.

9. Citation behavior:
   Never fabricate citations, quotations, pinpoints, docket entries, statutes, rules, dates, or authorities. Mark unverified citations as unverified.

10. Human review:
   Treat all output as draft work product for qualified lawyer review. Do not file, send, sign, publish, submit, or communicate externally.

The profile should be versioned like a prompt, not buried in an informal chat history. OpenAI’s prompt engineering guidance recommends prompt versioning and testing for production uses. For a law firm or legal department, that means recording which preference profile was used for a draft, who approved it, when it was changed, and whether it passed matter-specific review. If a lawyer’s preferences vary by client, forum, practice group, or output type, the profile should not be global; it should be selected for the matter.

Numbered lists: structure helps review and redlining

Numbered lists are more than a stylistic preference. They help reviewers refer to specific propositions, compare drafts, isolate weak reasoning, and assign verification tasks. A supervising lawyer can say “verify paragraph 4.2 and move 5.1 to the adverse-authority section,” which is more precise

Modular drafting workflow: from claim map to lawyer sign-off

OpenAI’s Harvey customer story describes a pattern in which legal work benefits from combining matter sources, case-law research, firm documents, court information, and explicit lawyer preferences such as numbered lists, prioritizing EDGAR, or color-coding issues by priority. This section turns that documented pattern into an operational workflow for legal teams, but it does not claim to reproduce Harvey, its controls, its security posture, or its legal quality. The goal is narrower: create drafts whose claims can be traced, challenged, verified, revised, and approved by a qualified lawyer before any consequential use.

The workflow below treats drafting as a sequence of modules rather than a single “write my brief” prompt. Each module has a discrete task, a required input set, a refusal rule for missing sources, and a verification artifact. This design follows OpenAI’s prompt-engineering guidance to give explicit instructions and structured context, and it aligns with OpenAI’s safety guidance that high-stakes work should use human-in-the-loop review, constrained inputs, and appropriate safeguards.

Use this workflow only with authorized, properly handled material. Do not upload or paste privileged, confidential, personal, regulated, sealed, proprietary, or client-sensitive content unless the responsible lawyer has confirmed authorization, necessity, and the applicable technical and professional controls. Do not treat any generated text as final legal advice, a filing-ready document, a client communication, or a substitute for a lawyer’s independent judgment.

Module 1: Claim map before prose

A claim map is the skeleton of a legal draft. It lists the propositions the draft might assert before the model is asked to write polished paragraphs. This prevents a fluent memorandum from hiding unsupported leaps, stale authorities, or mixed factual and legal conclusions. The claim map should separate factual assertions, procedural assertions, rule statements, application arguments, requested relief, and open questions.

Recommended use: run the claim-map module immediately after the source packet, authority hierarchy, chronology, issue map, and preference profile are assembled. If the source packet is incomplete, ask for a claim map of “potential propositions requiring verification,” not a finished argument.

Copy-paste template: Claim map generator

Role:
You are assisting with an internal legal drafting workflow. You are not providing final legal advice, filing language, or client communications.

Authorization and source limits:
Use only the sources listed in the source packet below. Do not rely on outside knowledge, unlisted cases, unlisted statutes, memory, assumptions, or inferred facts. If a proposition lacks support in the packet, mark it "UNSUPPORTED—SOURCE NEEDED" and do not complete it silently.

Jurisdiction and date scope:
[Insert jurisdiction]
[Insert relevant date range/currentness cutoff]
[Insert procedural posture]

Task:
Create a claim map for the requested draft. Separate:
1. Factual propositions
2. Procedural propositions
3. Legal rule propositions
4. Application propositions
5. Anticipated counterarguments
6. Requested relief or business objective
7. Open questions and missing sources

Required output:
Use a table with these columns:
- Claim ID
- Draft section
- Proposed proposition
- Proposition type
- Supporting source ID(s)
- Source location reference
- Verification status: Verified from packet / Needs lawyer review / Unsupported—source needed
- Risk note
- Suggested next action

Do not write final prose yet.

The main decision rule is simple: a proposition without a source does not become a confident sentence. It can remain in the working set as a hypothesis, lawyer question, or research task, but it should not be smoothed into the draft. In legal workflows, silence about uncertainty is more dangerous than an incomplete table.

Module 2: Proposition-to-source ledger

The proposition-to-source ledger is the central verification artifact. It should survive beyond drafting and accompany the memorandum through review. Every material statement should point to a source ID, source location, source type, and verification status. This is more precise than a general bibliography because it connects each sentence-level or paragraph-level proposition to the evidence supporting it.

Recommended use: require the model to produce or update the ledger before generating each draft section. The ledger should also identify sources that are persuasive but not controlling, sources that are potentially adverse, and sources whose currentness has not been confirmed.

Copy-paste template: Proposition-to-source ledger

Task:
Create a proposition-to-source ledger for the draft section described below. Do not draft prose. Do not invent authorities, citations, record references, exhibit numbers, quotation text, docket numbers, statutes, regulations, dates, or holdings.

Draft section:
[Insert section name]

Available source packet:
[Paste source manifest with source IDs only; include short descriptions and authorized location references]

Claim map:
[Paste relevant claim IDs]

Output table columns:
- Ledger ID
- Claim ID
- Exact proposition to be drafted
- Source ID(s)
- Source type: court filing / order / transcript / case / statute / regulation / contract / correspondence / EDGAR / firm template / other authorized source
- Pinpoint or location reference from packet
- Authority level: controlling / persuasive / factual record / background / unknown
- Currentness status: checked as of [date] / not checked / outside model task
- Quotation required? yes/no
- Citation required? yes/no
- Adverse authority flag
- Confidence basis from sources
- Required lawyer review question

Rules:
If no source supports a proposition, write "UNSUPPORTED—DO NOT DRAFT AS FACT OR LAW."
If a citation is incomplete, write "INCOMPLETE CITATION—VERIFY BEFORE USE."
If a quotation is not present in the packet, write "QUOTE NOT AVAILABLE—DO NOT QUOTE."

This deep-research guide explains source controls, live steering, citations, and editable deliverables in ChatGPT Work and Codex, offering a concrete verification workflow that legal teams can adapt for proposition, citation, and quotation audits. The How to Run Deep Research in ChatGPT Work and Codex: Source Controls, Live Steering, Citations, and Editable Deliverables article is a focused companion for Citation and Quotation Audit because the target centers on source controls and citation handling, making it more directly relevant to evidence auditing than a broad academic-prompt list.

The ledger also creates a clean division of labor. The model can organize source references and expose gaps, while the lawyer or trained reviewer verifies the authorities in the approved research system, the docket, the record, or the firm’s document-management environment. For consequential work, do not outsource the ultimate truth of a citation, quotation, holding, or procedural posture to generated text.

Module 3: Quotation verification

Quotation verification requires stricter rules than ordinary summarization. A generated quotation must never be treated as authentic merely because it is plausible or formatted with quotation marks. The safest drafting pattern is to provide the exact source excerpt in the packet, require the model to use only that excerpt, and have a human compare the draft quote against the authoritative source before use.

Operational warning: do not ask the model to “find a quote” unless the tool or workflow is connected to an authorized, verified source environment and the reviewer will confirm the quotation. In a plain prompt workflow, provide the excerpt yourself or ask for a placeholder that says a quotation is needed.

Copy-paste template: Quotation verification table

Task:
Review the proposed quotations below against the provided source excerpts only. Do not repair, complete, paraphrase as a quotation, or invent missing words. If the exact quoted language is not present in the excerpt, mark it as a mismatch.

Provided source excerpts:
[Insert exact excerpts with source IDs and location references]

Proposed quotations:
[Insert draft quotations]

Output table columns:
- Quote ID
- Proposed quoted text
- Source ID
- Source location reference
- Exact match? yes/no
- Differences found
- Ellipses/brackets used? yes/no
- Does the alteration change meaning? reviewer must assess
- Safe draft action: keep / revise to exact excerpt / convert to paraphrase / remove / lawyer review required

Rules:
Do not create new quotations.
Do not add citation details that are not provided.
Do not infer surrounding context beyond the excerpt.
If context is necessary to assess meaning, write "CONTEXT NEEDED—LAWYER REVIEW."

Quotations also need context review. An exact sentence can still be misleading if the surrounding paragraph narrows it, distinguishes the facts, states an exception, or appears in dissent, dicta, a party brief, or a reversed decision. The verification table should therefore identify exact-text accuracy, while the supervising lawyer assesses legal significance.

Module 4: Citation verification

Citation verification is a separate control from quotation verification. A correct quote can carry an incomplete citation, and a well-formatted citation can point to the wrong authority. The verification process should check citation components, authority identity, court or issuing body, date, pinpoint reference, subsequent history or treatment where applicable, jurisdictional relevance, and whether the proposition actually matches the source.

Recommended use: ask the model to create a citation checklist from the sources you provide, not to certify that all citations are legally valid. Final citation validation belongs to a qualified lawyer or trained legal professional using approved research tools and matter systems.

Copy-paste template: Citation verification request

Role:
You are preparing a citation audit checklist for human review. You do not certify legal correctness.

Inputs:
Draft passage:
[Paste passage]

Citation/source packet:
[Paste source IDs, citations as provided by the lawyer or research platform, and authorized location references]

Task:
Create a citation verification checklist. Do not invent missing reporter information, docket numbers, statutory sections, regulatory subsections, dates, courts, parentheticals, subsequent history, or pinpoint pages.

Output table columns:
- Citation ID
- Draft sentence or proposition
- Citation as drafted
- Source ID
- Citation completeness status: complete as provided / incomplete / inconsistent / not in packet
- Pinpoint present? yes/no
- Proposition supported by cited source? supported / partially supported / not shown in packet / lawyer review required
- Currentness or treatment check required? yes/no
- Jurisdiction relevance issue? yes/no
- Formatting issue to review
- Human verification action

Rules:
If a citation is not in the packet, write "SOURCE NOT PROVIDED—VERIFY OR REMOVE."
If the draft cites a source for a proposition not shown in the packet, write "SUPPORT NOT SHOWN—LAWYER REVIEW."
Do not state that a case, statute, regulation, or filing is current unless the packet includes a currentness check.

OpenAI’s evaluation guidance is useful here as an operating principle: define what “good” means before relying on outputs. For a legal citation audit, “good” should mean not merely plausible formatting but traceable identity, source support for the proposition, currentness review, and human approval. A team can sample drafts, record error categories, and improve the prompt or source-packet format when recurring issues appear.

Module 5: Adverse-authority search request

Adverse authority is a professional and strategic issue, not a formatting issue. A model can help structure a request for adverse-authority research, but the actual search should be performed through approved research systems and reviewed by a qualified lawyer. The prompt should never imply that no adverse authority exists merely because none appears in the provided packet.

Copy-paste template: Adverse-authority search request builder

Task:
Prepare a research request for a qualified legal researcher or supervising lawyer. Do not conduct the research unless authorized tools and sources are provided. Do not state that adverse authority does or does not exist.

Matter context:
[Insert jurisdiction, procedural posture, issue, currentness date, and relevant facts]

Position to test:
[Insert proposed legal proposition or argument]

Known supporting authorities:
[Insert source IDs and citations from packet]

Known potentially adverse materials:
[Insert any known contrary sources or write "None provided"]

Required output:
1. Research question
2. Jurisdiction and date boundaries
3. Key terms and legal concepts to search
4. Authority hierarchy to apply
5. Types of adverse material to look for:
   - contrary controlling authority
   - limiting or distinguishing cases
   - negative treatment
   - statutory or regulatory amendments
   - procedural bars
   - factual distinctions
   - local rule issues
6. Output format for the researcher:
   - authority
   - adverse point
   - relevance
   - treatment/currentness
   - effect on draft
   - lawyer recommendation needed

Rules:
Use cautious language. Write "adverse-authority search required" unless the supervising lawyer confirms completion.
Do not mark any argument as final until adverse authority has been reviewed.

This module is especially important when the source packet is assembled from one side’s preferred authorities, a prior brief, or a research memo prepared for a different procedural posture. The absence of adverse authority in those materials is not evidence that adverse authority does not exist.

Module 6: Missing-evidence log

The missing-evidence log is the antidote to silent completion. It lists every place where the draft wants a fact, authority, exhibit, currentness check, record citation, client instruction, procedural rule, or strategic decision that is not yet available in the source packet. The log should be reviewed before any section is elevated from working draft to lawyer-review draft.

Copy-paste template: Missing-evidence log

Task:
Identify missing evidence, missing authority, incomplete citations, unsupported factual assertions, and unresolved instructions in the draft materials. Do not fill gaps from assumptions or general knowledge.

Inputs:
Claim map:
[Paste claim map]

Proposition-to-source ledger:
[Paste ledger]

Draft text, if any:
[Paste draft]

Output table columns:
- Gap ID
- Affected draft section
- Missing item
- Why it matters
- Current unsupported language, if any
- Source type needed
- Suggested owner: lawyer / paralegal / researcher / client team / subject-matter expert
- Risk level: high / medium / low
- Draft action until resolved: remove / bracket / qualify / convert to question / leave out
- Deadline or dependency

Rules:
If a missing item affects a legal conclusion, mark "LAWYER REVIEW REQUIRED."
If a missing item affects client facts, mark "CLIENT OR RECORD CONFIRMATION REQUIRED."
If the draft cannot responsibly proceed without the item, write "STOP—DO NOT FINALIZE THIS SECTION."

A mature missing-evidence log should be uncomfortable to read because it exposes the draft’s weak points. That discomfort is useful. It gives the supervising lawyer a concrete list of decisions instead of a polished document that conceals uncertainty.

Module 7: Uncertainty register

The uncertainty register is different from the missing-evidence log. Missing evidence is about absent inputs; uncertainty is about ambiguity, conflicting sources, unresolved legal treatment, factual disputes, strategic choices, and model limitations. A draft can have complete source references and still contain uncertainty that must be disclosed internally.

Copy-paste template: Uncertainty register

Task:
Create an uncertainty register for the current draft. Do not resolve uncertainty by guessing. Do not make legal, strategic, or client-advice decisions.

Inputs:
Draft:
[Paste draft]

Source ledger:
[Paste ledger]

Known adverse or conflicting materials:
[Paste if available]

Output table columns:
- Uncertainty ID
- Draft section
- Uncertainty category: factual / legal / procedural / citation / quotation / currentness / privilege / confidentiality / strategy / professional responsibility
- Description
- Competing interpretations or source conflict
- Impact if wrong
- Suggested qualification language, if appropriate
- Required reviewer
- Decision needed before final use
- Status

Rules:
Use explicit uncertainty labels.
Do not remove uncertainty labels from the draft unless a qualified reviewer resolves them.
If uncertainty affects a filing, external communication, legal advice, client commitment, or settlement posture, mark "QUALIFIED LAWYER SIGN-OFF REQUIRED."

The register is also a training artifact. Over multiple matters, recurring uncertainty categories can reveal problems in intake, source-packet design, research protocols, or preference profiles. OpenAI’s evaluation guidance supports this kind of systematic review: define failure modes, test workflows, and improve prompts and procedures rather than relying on ad hoc confidence.

Module 8: Privilege and confidentiality screen

A privilege and confidentiality screen should occur before drafting, before sharing a draft, and before using any generated text outside the authorized team. This screen is not a legal determination by the model. It is a structured checklist that helps the responsible lawyer identify material requiring heightened handling, redaction, exclusion, or separate analysis.

OpenAI’s account-security guidance also matters operationally: legal teams should protect access to accounts and workspaces, use strong authentication practices, review suspicious activity, and avoid credential sharing. Security hygiene does not answer privilege questions, but weak account controls can undermine the confidentiality assumptions that legal workflows depend on.

This technical guide explains how to implement ChatGPT-style memory systems in enterprise workflows, including architecture, personalization patterns, and privacy controls. The How to Implement ChatGPT’s Dreaming Memory System in Enterprise Workflows: Architecture, Personalization Patterns, and Privacy Controls article is a focused companion for Legal AI Memory Controls because legal AI memory controls require governed enterprise memory and privacy safeguards, which this target directly addresses.

Copy-paste template: Privilege and confidentiality screen

Role:
You are assisting with an internal issue-spotting checklist. You do not make final privilege, confidentiality, waiver, conflict, or professional-responsibility determinations.

Materials to screen:
[Describe or paste authorized, minimum-necessary text only]

Task:
Identify content categories that may require lawyer review, redaction, exclusion, access restriction, or special handling before drafting or sharing.

Output table columns:
- Item ID
- Material or passage reference
- Potential issue category:
  - attorney-client communication
  - attorney work product
  - client confidential information
  - personal data
  - regulated data
  - sealed or protective-order material
  - proprietary business information
  - third-party confidential information
  - settlement communication
  - conflict/professional-responsibility concern
  - unknown
- Why it is flagged
- Minimum-necessary use assessment
- Proposed handling: exclude / redact / summarize at higher level / restrict access / lawyer review / client confirmation
- External sharing allowed? no / not determined / lawyer approval required
- Notes for supervising lawyer

Rules:
Do not ask for additional sensitive details unless necessary and authorized.
Do not declare privilege waived or preserved.
Do not approve external sharing.
If in doubt, mark "LAWYER REVIEW REQUIRED."

The screen should be conservative. If the model flags too much, a lawyer can narrow the set. If it flags too little, sensitive material may be exposed, misused, or incorporated into a broader draft unnecessarily. In legal drafting, over-inclusion at the review stage is usually safer than silent under-identification.

Module 9: Draft section generation with embedded verification space

Only after the claim map, ledger, quotation review, citation checklist, adverse-authority request, missing-evidence log, uncertainty register, and confidentiality screen are in motion should the workflow produce substantive prose. The draft prompt should preserve verification space inside the output rather than generating a polished memo that separates prose from its evidence.

Copy-paste template: Controlled draft section

Role:
You are preparing an internal lawyer-review draft section. You are not providing final legal advice, filing-ready text, or client communication.

Source constraints:
Use only the approved source packet and ledger entries pasted below. Do not invent or silently complete facts, citations, quotations, authorities, procedural history, client instructions, or strategic decisions.

Draft section:
[Insert section title]

Audience:
[Internal legal team / supervising lawyer / research attorney / other authorized audience]

Preference profile:
[Insert approved drafting preferences, such as numbered lists, issue-priority labels, or source hierarchy. Preferences control format only; they do not change facts or law.]

Approved ledger entries:
[Paste ledger entries]

Known gaps and uncertainty:
[Paste relevant missing-evidence and uncertainty items]

Task:
Draft the section in lawyer-review form.

Required structure:
1. Draft text
2. Embedded source notes after each paragraph using [Source: ID/location]
3. Bracketed uncertainty flags where needed
4. Citation placeholders only where citation data is incomplete
5. No invented quotations
6. No final recommendation unless the supervising lawyer has provided it
7. End with "Reviewer questions"

Rules:
If a proposition is unsupported, omit it or bracket it as [UNSUPPORTED—SOURCE NEEDED].
If authority currentness is not confirmed, state [CURRENTNESS CHECK REQUIRED].
If adverse-authority review is incomplete, state [ADVERSE-AUTHORITY REVIEW REQUIRED].
If privilege/confidentiality review is needed, state [CONFIDENTIALITY REVIEW REQUIRED].

This draft format is intentionally less elegant than a finished memorandum. It is designed for reviewability. A supervising lawyer can remove brackets only after resolving the corresponding evidence, citation, privilege, or strategy issue. That is more reliable than trying to reconstruct the model’s reasoning after the prose has been polished.

Module 10: Redline comparison

Redline comparison is useful after a lawyer edits the draft, after new sources are added, or after a model-generated revision is requested. The comparison should focus on legal significance, not merely stylistic differences. A changed verb, deleted qualifier, added citation, or moved sentence can alter the legal position.

Copy-paste template: Redline comparison checklist

Task:
Compare the prior draft and revised draft for legally significant changes. Do not decide whether a change is legally correct. Identify changes requiring human review.

Prior draft:
[Paste prior text]

Revised draft:
[Paste revised text]

Source ledger:
[Paste relevant ledger entries]

Output table columns:
- Change ID
- Location
- Change type: fact / rule / application / citation / quotation / qualifier / relief / strategy / confidentiality / style only
- Prior language
- Revised language
- Potential legal significance
- Source support changed? yes/no/unclear
- Citation or quotation affected? yes/no
- New uncertainty introduced?
- Reviewer action required

Rules:
Flag any removed qualifier such as "alleged," "appears," "may," "subject to," or "based on the current record."
Flag any new authority, citation, quotation, date, amount, party name, procedural statement, or requested relief.
Do not approve the revision for external use.

Redline review should be mandatory when a prompt asks the model to “make this stronger,” “tighten the argument,” or “sound more confident.” Those instructions can unintentionally remove caution language, convert disputed facts into asserted facts, or make a legal conclusion appear settled. Strengthening prose must not weaken the verification record.

Module 11: Supervisory review and sign-off packet

The final module packages the work for a qualified lawyer. The sign-off packet should contain the draft, claim map, proposition-to-source ledger, quotation table, citation checklist, adverse-authority status, missing-evidence log, uncertainty register, confidentiality screen, redline comparison, and reviewer questions. The model can assemble the packet, but it cannot grant approval for filing, sending, advising, negotiating, publishing, or committing a client.

Copy-paste template: Supervisory review packet

Task:
Assemble a supervisory review packet for a qualified lawyer. Do not approve, file, send, publish, or finalize anything.

Matter:
[Insert matter name or internal identifier without unnecessary confidential details]

Draft purpose:
[Insert internal memo / motion section / contract issue list / client-question outline / other]

Included materials:
[Paste or list draft and verification artifacts]

Required output:
1. Executive review note
   - What the draft attempts to do
   - What sources it relies on
   - What remains unresolved
2. High-priority reviewer decisions
3. Source and citation issues requiring verification
4. Quotation issues requiring verification
5. Adverse-authority status
6. Privilege/confidentiality flags
7. Conflict or professional-responsibility questions
8. Redline changes requiring review
9. Final sign-off checklist

Final sign-off checklist:
- Authorized sources confirmed
- Jurisdiction and date scope confirmed
- Factual propositions verified
- Legal authorities verified
- Currentness checked
- Adverse authority reviewed
- Quotations checked against originals
- Citations checked against originals
- Privilege/confidentiality reviewed
- Professional-responsibility issues considered
- Client instructions confirmed where needed
- Filing, sending, publication, or other consequential action separately approved by authorized lawyer

Rules:
Use "Not confirmed" for any item that lacks evidence in the packet.
Do not mark any item complete unless the packet shows completion or the user explicitly states that a qualified reviewer has completed it.
End with: "Qualified lawyer review and explicit approval are required before any external or consequential use."

The sign-off packet should not be treated as bureaucracy. It is the evidence trail that distinguishes a controlled context-to-draft workflow from a risky text-generation shortcut. If the draft later changes, the affected ledger entries, uncertainty items, citations, and redline notes should change with it.

Putting the modules together in a repeatable sequence

The modular workflow works best when the team runs it in a fixed order and resists the temptation to skip directly to prose. The exact process can vary by matter type, jurisdiction, workspace policy, and available research systems, but the sequence below gives legal teams a conservative default.

1. Confirm authorization and scope. Identify who approved use of the materials, what may be processed, what must be excluded, and which systems are approved.
2. Assemble the source packet. Include source IDs, descriptions, dates, location references, authority hierarchy, and exclusions.
3. Create the claim map. Convert the issue map into propositions without drafting final prose.
4. Create the proposition-to-source ledger. Attach each material proposition to source IDs and location references.
5. Run quotation and citation checks. Treat quotations and citations as unverified until checked against authoritative sources.
6. Request adverse-authority review. Prepare the research request and mark the draft accordingly until the review is complete.
7. Log missing evidence and uncertainty. Keep unresolved items visible in the draft workflow.
8. Screen for privilege and confidentiality issues. Exclude, redact, restrict, or escalate materials as needed.
9. Draft sections with embedded source notes. Use lawyer-review format, not final-client format.
10. Compare revisions by legal significance. Flag new or changed claims, citations, quotations, relief, and qualifiers.
11. Prepare the supervisory sign-off packet. Require qualified lawyer approval before any external or consequential action.

This sequence also creates practical checkpoints for enterprise administrators and legal-operations teams. A workspace policy can require source manifests, restrict external sharing, define approved repositories, require human approval for filings and communications, and prohibit processing of sensitive material outside approved systems. Those controls should be documented locally because product behavior, account features, regional availability, and workspace settings can vary.

Operational rule for legal teams: if a draft cannot show where a material proposition came from, whether the source is current, whether contrary authority was considered, and who approved the final use, it is not ready for external reliance.

Quality-control metrics that do not pretend to measure legal correctness

Legal teams can evaluate this workflow without claiming that a model is “legally correct.” Useful measures include percentage of material propositions with source IDs, number of unsupported propositions removed before review, citation issues found per draft, quotation mismatches caught, unresolved currentness checks, adverse-authority research requests completed, confidentiality flags escalated, and lawyer-review changes by category.

Sample matter note for communication control:

Document: Draft memorandum on issue preclusion
AI-assisted: Yes
Use level: Lawyer review draft only
External transmission approved: No
Filing approved: No
Client communication approved: No
Required before external use:
- Verify all citations against primary sources
- Confirm jurisdiction/date scope
- Complete adverse-authority review
- Complete privilege/confidentiality screen
- Supervising lawyer sign-off

Sample closing classification:

Official matter file:
- Final signed memorandum
- Final source packet manifest
- Citation and quotation verification ledger
- Supervising lawyer sign-off record
- Client or filing transmission record, if applicable

Quality-review repository:
- Redacted workflow notes
- De-identified prompt improvement observations
- Checklist failures and corrective actions

Delete under policy if not subject to hold:
- Temporary extraction files
- Duplicate AI drafts
- Superseded prompt experiments
- Non-substantive working copies
- Screenshots containing unnecessary confidential information