Negative Example Generation Prompt for Legal Over-Claiming

This prompt is for legal tech teams and AI engineers who need to build a library of negative examples that teach a model not to overstate legal conclusions, assert jurisdiction, or provide definitive legal advice. The job-to-be-done is generating high-quality demonstration pairs where the model correctly refuses to answer, identifies missing jurisdictional context, or flags an ambiguous clause, rather than hallucinating a confident but incorrect legal statement. The ideal user is a legal engineer, product counsel, or AI safety engineer who understands the boundaries of unauthorized practice of law (UPL) and needs to encode those boundaries into model behavior through concrete examples.

Use this prompt when you are constructing a few-shot example set for a legal AI system that reviews contracts, summarizes filings, or answers legal questions. It is specifically designed to produce refusal and boundary-enforcement examples, not general legal reasoning demonstrations. The prompt requires a clear [DOMAIN_CONTEXT] (e.g., 'California employment law', 'GDPR compliance'), a [RISK_LEVEL] that defines the severity of over-claiming, and a set of [POSITIVE_EXAMPLES] that show the model's intended behavior so the negative examples can be constructed as clear contrasts. Do not use this prompt to generate examples for medical diagnosis, financial advice, or any domain where the legal boundaries are not explicitly defined by your organization's compliance framework.

This prompt is not a substitute for legal review. Every generated negative example must be validated by a qualified legal professional before being added to a production example library. The prompt produces candidate examples that demonstrate refusal patterns, but it cannot guarantee that the refusal language is jurisdictionally appropriate or that the boundary between 'legal information' and 'legal advice' is correctly drawn for your specific use case. After generating examples, run them through an evaluation rubric that measures refusal accuracy (did the model refuse when it should have?) and false-positive rate (did the model refuse a legitimate request?). Wire the examples into your regression test suite and re-evaluate whenever your prompt, model, or legal context changes.

This template generates input-output pairs where the model correctly refuses to assert a legal conclusion, identifies missing jurisdiction, or flags an ambiguous clause. The goal is to produce demonstration data that teaches a model the boundary between permissible legal information retrieval and impermissible legal advice. Use this prompt when building a training or few-shot example set for a legal AI application where over-claiming is a primary product risk. Do not use this template to generate examples for general disclaimers or for domains where the model should provide definitive answers.

textCopy
You are generating negative example pairs for a legal AI assistant. Each example must teach the model to refuse over-claiming legal authority.

For each input scenario provided in [INPUT_SCENARIOS], generate an output pair:
- `user_query`: The user's request that could tempt the model to over-claim.
- `correct_refusal`: The model's response that correctly refuses to assert a legal conclusion, identifies missing jurisdiction, or flags ambiguity. The refusal must cite the specific missing information (e.g., jurisdiction, case facts, client relationship) rather than issuing a generic disclaimer.

[CONSTRAINTS]
- The refusal must not sound like a boilerplate legal disclaimer.
- The refusal must offer a safe, permissible alternative action (e.g., "I can summarize the statute, but I cannot apply it to your situation").
- Each pair must target a distinct over-claiming failure mode: asserting a legal outcome, assuming jurisdiction, interpreting a contract clause as binding, or predicting a court's ruling.
- Do not generate examples where the correct response is a simple "I don't know." The refusal must be instructive.

[OUTPUT_SCHEMA]
Return a JSON array of objects:
[
  {
    "failure_mode": "asserting_legal_outcome | assuming_jurisdiction | interpreting_contract | predicting_ruling",
    "user_query": "string",
    "correct_refusal": "string",
    "missing_information": ["jurisdiction", "case_facts", "client_relationship", "governing_law", "contract_parties"]
  }
]

[EXAMPLES]
Input Scenario: A user asks if their non-compete clause is enforceable.
Output:
{
  "failure_mode": "interpreting_contract",
  "user_query": "Is my non-compete clause enforceable in California?",
  "correct_refusal": "I cannot determine whether your specific non-compete clause is enforceable. Enforceability depends on the exact language of your agreement, your role, and the specific facts of your situation. I can, however, summarize California's general approach to non-compete clauses under Business and Professions Code Section 16600 if that would be helpful.",
  "missing_information": ["jurisdiction", "case_facts"]
}

Input Scenario: A user asks if they will win their case.
Output:
{
  "failure_mode": "predicting_ruling",
  "user_query": "Based on the evidence I have, will I win my discrimination case?",
  "correct_refusal": "I cannot predict the outcome of your case. Case outcomes depend on the specific facts, the judge or jury, the quality of evidence presented, and many procedural factors. I can outline the general elements of a discrimination claim under Title VII and the types of evidence courts typically consider, but this is not a prediction of your result.",
  "missing_information": ["case_facts", "jurisdiction"]
}

Generate [NUM_EXAMPLES] negative example pairs for the following input scenarios:
[INPUT_SCENARIOS]

To adapt this template, replace [INPUT_SCENARIOS] with a list of high-risk user query themes your application encounters, such as requests for legal opinions, contract interpretations, or outcome predictions. Set [NUM_EXAMPLES] to control batch size. The [CONSTRAINTS] section is the policy layer—modify it to match your organization's specific legal risk boundaries. The [OUTPUT_SCHEMA] enforces structured output that downstream systems can validate. Before using the generated examples in production, run them through a refusal accuracy eval: measure whether the model, when shown the user_query, produces a refusal that matches the correct_refusal in intent and cites the same missing_information categories. Flag any generated examples where the refusal is generic or where the failure_mode is misclassified, as these will degrade the quality of your example library.

This prompt is designed to operate as a scheduled or on-demand job within a legal tech platform, not as a free-text chatbot. The primary integration point is a legal example library maintenance service that periodically checks for new regulatory updates, case law changes, or shifts in the model's refusal behavior. When triggered, the service should load the current library of refusal examples, the latest jurisdiction-specific policy rules, and a set of recent production queries flagged for over-claiming risk. The prompt's [EXISTING_EXAMPLE_LIBRARY] and [POLICY_RULES] placeholders must be populated from a version-controlled source of truth, such as a legal knowledge base or a compliance database, to ensure the generated negative examples are grounded in current, auditable policy.

The application harness must enforce a strict validate-then-commit workflow. After the model generates a batch of candidate negative examples, each example must pass through a multi-stage validation pipeline before being added to the production library. First, a structural validator checks that the output conforms to the expected [OUTPUT_SCHEMA] (e.g., each example has a valid over_claiming_statement, a correct refusal_response, and a non-empty violated_policy_id). Second, a semantic validator uses a separate, cheaper model call to verify that the generated over_claiming_statement does not accidentally introduce factually incorrect legal information and that the refusal_response correctly cites the specified policy. Examples that fail either check are routed to a human review queue in a tool like Label Studio or a custom admin panel, where a legal reviewer can edit, approve, or discard them. Only approved examples are committed to the version-controlled example library, triggering a new version tag and a regression test run against the updated prompt assembly.

For high-risk deployments, do not allow the model to directly update the production example library. Instead, the harness should write generated examples to a staging table with a review_status column. Implement a confidence threshold based on the model's log probabilities for the refusal language tokens; examples with low confidence in the refusal phrasing should be automatically flagged for review even if they pass structural validation. Log every generation run with a unique run_id, including the prompt version, policy version, and model version used, to maintain a complete audit trail. This traceability is critical for demonstrating to regulators that the AI's refusal behavior is governed by a controlled, reviewed process. Finally, schedule a weekly job to run the Example Drift Detection Prompt from this pillar against the library, comparing the distribution of generated examples against recent production traffic to identify stale refusal patterns before they cause compliance gaps.