Legal Contract Drafting Boundary Prompt

This prompt is designed for legal tech AI tools that assist with document generation. Its primary job is to enforce a strict boundary: the system must refuse to draft a complete, executable legal contract without attorney review. It identifies clauses requiring customization and maintains a clear separation between providing a template and creating a legal instrument. Use this prompt when your application allows users to request contract generation and you need a programmatic guardrail against the unauthorized practice of law (UPL). This is not a general legal advice refusal prompt; it is specifically calibrated for the contract drafting workflow where the risk of UPL is highest.

Deploy this prompt in any user-facing feature where a user can describe a desired legal outcome and ask the model to produce a contract. Typical integration points include a 'Generate Contract' button in a legal document builder, a chat interface where users describe a business deal, or an API endpoint that accepts contract parameters. The prompt should sit between the user's request and the model's drafting output, acting as a policy layer that inspects the request for completeness, flags clauses that require attorney customization (such as indemnification, limitation of liability, or governing law), and either refuses to generate a full executable contract or wraps the output in a structured disclaimer and review notice. Do not use this prompt for general legal Q&A, case law summarization, or document review workflows—those require different refusal and disclaimer patterns covered in the Legal Advice Boundary Enforcement and Legal Document Interpretation Disclaimer playbooks.

Before wiring this prompt into production, define the exact trigger conditions. The prompt should activate when the user's request implies creation of a binding legal instrument: phrases like 'draft a contract,' 'write an agreement,' 'create an NDA,' or 'prepare terms and conditions' are clear signals. If your application only offers template selection from a pre-approved library with no AI-generated clause customization, this prompt may be unnecessary. Conversely, if your application allows free-form clause generation or modification, this prompt becomes a required safety control. Pair it with a downstream human review queue for any output that passes the boundary check but still contains attorney-review-required clauses. Log every refusal and every clause flag for audit and product improvement.

This prompt template is designed to sit in your system instructions for any legal tech AI feature that assists with document generation. Its job is to draw a clear, defensible boundary: the model may provide templates, identify clauses that require customization, and explain legal concepts, but it must refuse to draft a complete, executable legal instrument without attorney review. The template uses square-bracket placeholders so you can adapt it to your specific jurisdiction, product context, and risk tolerance without rewriting the core refusal logic.

textCopy
You are an AI assistant integrated into a legal document preparation tool. Your role is to help users understand and prepare legal document templates, not to act as their attorney or to produce final, executable legal instruments.

## Core Rule
You must refuse to draft a complete contract, agreement, or legal instrument that is ready for execution without attorney review. You may provide template language, identify clauses that require customization, explain legal concepts, and flag sections that carry elevated risk. You must never represent that your output constitutes legal advice or a substitute for professional legal review.

## Inputs
- [USER_REQUEST]: The user's natural-language description of what they want.
- [DOCUMENT_TYPE]: The category of legal document (e.g., NDA, employment agreement, service contract).
- [JURISDICTION]: The governing legal jurisdiction, if known.
- [PARTY_CONTEXT]: Known information about the parties involved, if any.
- [RISK_LEVEL]: One of LOW, MEDIUM, HIGH, or CRITICAL, set by the application based on document type and jurisdiction.

## Output Rules
1. If [RISK_LEVEL] is HIGH or CRITICAL, you must begin your response with: "I cannot draft a complete [DOCUMENT_TYPE]. This document requires attorney review because [specific reason]. I can instead provide a template with placeholders and identify the clauses that need customization."
2. If [RISK_LEVEL] is MEDIUM, you may provide template clauses but must include the disclaimer: "The following is a template only and does not constitute legal advice. An attorney must review and adapt this language to your specific circumstances before use."
3. If [RISK_LEVEL] is LOW, you may provide more complete template language but must still include a clear disclaimer and identify any clauses that depend on jurisdiction-specific law.
4. Never state or imply that a document you produce is legally sufficient, complete, or ready for execution.
5. If the user asks you to act as their attorney, provide legal advice, or predict a legal outcome, refuse and explain that you are a document preparation tool, not a lawyer.

## Output Format
Return a JSON object with the following schema:
{
  "action": "REFUSE" | "TEMPLATE" | "EXPLAIN",
  "disclaimer": "string (required for TEMPLATE and EXPLAIN actions)",
  "content": "string (the template text, explanation, or refusal message)",
  "flagged_clauses": ["list of clause names requiring attorney review"],
  "jurisdiction_notes": "string (if jurisdiction-specific concerns apply)"
}

## Constraints
- Do not draft complete contracts for HIGH or CRITICAL risk levels.
- Do not remove or soften the disclaimer text.
- Do not recommend specific legal actions or strategies.
- Do not predict how a court or regulator would interpret a clause.

To adapt this template for your application, start by defining your [RISK_LEVEL] mapping in application code before the prompt reaches the model. For example, an NDA in a single jurisdiction with standard terms might be LOW, while a cross-border M&A agreement should be CRITICAL. Wire the output JSON through a post-processing validator that checks for the presence of the disclaimer field on every TEMPLATE and EXPLAIN action, and log any response where the action is TEMPLATE but the disclaimer is missing or truncated. For production deployments, pair this prompt with an eval suite that includes test cases for each risk level, boundary-pushing requests (e.g., "just make it ready to sign"), and jurisdiction-specific edge cases. Human review should be required for any output where [RISK_LEVEL] is CRITICAL or where the model's action does not match the expected action for the given risk level.

This prompt is designed to sit at the boundary between a user's request for a legal document and the AI's generation capabilities. In a production application, it should be deployed as a pre-generation gate—a synchronous check that runs before any drafting model is invoked. The prompt itself does not draft; it classifies the request, identifies risky clauses, and either refuses, redirects, or passes a scoped-down request to a downstream drafting prompt. The implementation harness must enforce that this boundary prompt's decision is respected: if it returns a refusal or a redline requiring human review, the application must not proceed to generation.

Integration pattern: Place this prompt in a lightweight, fast-inference model (such as a small Claude Haiku or GPT-4o-mini) to minimize latency. The output schema should be strict JSON with fields: decision (enum: refuse, redirect, proceed_with_caveats), refusal_reason (string), identified_risky_clauses (array of strings), safe_scope (string describing what can be generated), and requires_human_review (boolean). Validate this JSON before acting on it. If requires_human_review is true, route the request to a review queue and notify the user that an attorney must review before generation. If decision is refuse, return the refusal_reason to the user and log the interaction. If decision is proceed_with_caveats, pass only the safe_scope string to the drafting prompt—never the original user request.

Validation and retry logic: Implement a JSON schema validator that checks the output against the expected structure. If validation fails, retry once with the same prompt and a repair instruction appended (e.g., 'Your previous output was not valid JSON. Return only valid JSON matching the required schema.'). If the second attempt fails, escalate to a human operator and log the failure for prompt debugging. Logging: Log every invocation with the user request, the model's decision, the identified risky clauses, and whether human review was triggered. This audit trail is critical for demonstrating that your system has a documented boundary between template provision and legal instrument creation—a key defense against unauthorized practice of law claims.

Human review integration: When requires_human_review is true, the application should create a review task in your legal operations system (e.g., a Jira ticket, a Slack notification to the legal team, or a dedicated review dashboard). The review task must include the original user request, the model's risk assessment, and a link to approve or deny the generation. Only after a qualified human approves should the safe_scope be passed to the drafting model. Model choice: Use a model with strong instruction-following and low refusal drift for this boundary prompt. Claude 3.5 Sonnet or GPT-4o are appropriate for higher-risk deployments; smaller models may be sufficient if you run regular eval checks against your refusal test suite. What to avoid: Never bypass this boundary prompt for logged-in or 'trusted' users. The legal risk does not decrease with user role. Never cache or reuse boundary decisions across different user requests—each request must be independently evaluated.