Mandatory Disclaimer and Legal Text Inclusion Check Prompt

This prompt is for regulated-domain teams who need to programmatically verify that AI-generated outputs contain required legal text, disclaimers, or copyright notices before those outputs reach a user or a downstream system. The job-to-be-done is not to generate the disclaimer itself, but to act as a deterministic compliance gate. The ideal user is an AI engineer or a compliance officer embedding this check into a CI/CD pipeline, a content moderation queue, or a pre-release review workflow. You should use this prompt when the cost of a missing disclaimer is high—such as in finance, healthcare, or legal tech—and when a simple string match is insufficient because the model may paraphrase the required text.

Do not use this prompt as a substitute for legal review. It is a structural and semantic check, not a legal opinion. It is also not designed for checking the factual accuracy of the disclaimer's content, only its presence and placement. The prompt requires a clear input: the [GENERATED_OUTPUT] to be checked, and a [REQUIRED_DISCLAIMERS] list that can include exact strings, semantic concepts, or regex patterns. You must also configure a [MATCH_TOLERANCE] to decide whether a semantic near-match is acceptable or if an exact string match is required. The output is a structured compliance report, not a pass/fail boolean, so your application logic can decide how to handle partial compliance or placement violations.

Before wiring this into a production system, define your failure modes. A false positive (flagging a present disclaimer as missing) creates a manual review bottleneck. A false negative (missing a genuinely absent disclaimer) is a compliance violation. Start by running this prompt against a golden dataset of 50-100 known-compliant and known-non-compliant outputs to calibrate the tolerance and understand the judge model's behavior. If your regulatory requirements demand exact text, set the tolerance to 'exact' and pair this prompt with a post-processing string-diff check. If semantic equivalence is acceptable, use a capable judge model and implement a human review step for any 'partial_match' results before the system matures.

This prompt template is designed to be copied directly into your evaluation harness. It instructs the model to act as a compliance auditor, checking whether a generated output contains all required disclaimers, legal notices, or regulatory text. The template uses square-bracket placeholders that you must replace with your specific requirements before use. Every placeholder is documented so you can wire this into an automated pipeline or a manual review queue.

textCopy
You are a compliance auditor. Your task is to verify that the provided output includes all mandatory disclaimers, legal text, and required notices specified in the [REQUIRED_TEXT_LIST].

For each required text item, determine whether it appears in the output. Apply the matching tolerance specified in [MATCH_CONFIG].

[REQUIRED_TEXT_LIST]:
- [ITEM_1]
- [ITEM_2]
- [ITEM_N]

[MATCH_CONFIG]:
{
  "mode": "[EXACT_MATCH | SEMANTIC_MATCH | REGEX_MATCH]",
  "case_sensitive": [TRUE | FALSE],
  "min_similarity_threshold": [0.0-1.0],
  "allow_reordering": [TRUE | FALSE]
}

[PLACEMENT_RULES]:
- [PLACEMENT_RULE_1]
- [PLACEMENT_RULE_2]

[OUTPUT_TO_AUDIT]:
"""
[OUTPUT_TEXT]
"""

Produce a JSON report with this exact schema:
{
  "overall_compliance": "[FULLY_COMPLIANT | PARTIALLY_COMPLIANT | NON_COMPLIANT]",
  "items": [
    {
      "required_text_id": "string",
      "required_text": "string",
      "found": true | false,
      "match_type": "[EXACT | SEMANTIC | NONE]",
      "match_confidence": 0.0-1.0,
      "matched_location": "string | null",
      "placement_compliant": true | false | "NOT_APPLICABLE",
      "evidence_snippet": "string | null"
    }
  ],
  "missing_items_count": 0,
  "placement_violations_count": 0,
  "summary": "string"
}

[CONSTRAINTS]:
- [CONSTRAINT_1]
- [CONSTRAINT_2]

Before returning the JSON, verify that every required text item has been checked. If [RISK_LEVEL] is HIGH, flag any uncertainty for human review in the summary field.

Adapt this template by replacing each square-bracket placeholder with concrete values. For [REQUIRED_TEXT_LIST], list every mandatory disclaimer, copyright notice, legal clause, or regulatory statement that must appear. For [MATCH_CONFIG], choose EXACT_MATCH for verbatim text, SEMANTIC_MATCH for meaning-equivalent checks with a similarity threshold, or REGEX_MATCH for pattern-based detection. Define [PLACEMENT_RULES] to specify where text must appear—such as "must be in the first paragraph" or "must appear before any actionable advice." Set [RISK_LEVEL] to HIGH for regulated domains where false negatives carry legal exposure; this triggers the human-review flag in the summary. Remove any placeholder you don't need, but never leave a placeholder unresolved when deploying to production.

This prompt is designed to operate as a post-generation compliance gate inside a larger content pipeline. The typical integration pattern places it immediately after content generation and before any downstream publishing, API delivery, or user-facing display step. The prompt expects two primary inputs: the generated content to audit ([CONTENT]) and a structured list of required disclaimers or legal text blocks ([REQUIRED_DISCLAIMERS]). Each required disclaimer entry should include an identifier, the exact text or a semantic description, placement requirements (e.g., 'must appear in the first paragraph', 'must be the final sentence'), and a match tolerance setting (exact or semantic). The output is a structured JSON compliance report that your application can parse and act on programmatically.

Validation and retry logic is critical because this prompt sits in a high-risk workflow. Implement a JSON schema validator on the model's output to confirm the report contains the expected fields: compliance_status, checked_disclaimers (array of objects with id, found, match_type, placement_valid, notes), and missing_disclaimers. If the output fails schema validation, retry once with a stronger instruction to return valid JSON only. If the second attempt also fails, escalate to a human review queue and log the raw output for debugging. For exact match configurations, consider pre-processing the required text and the generated content with whitespace normalization and Unicode canonicalization before passing them to the prompt, reducing false negatives from invisible character differences.

Model choice and latency considerations matter here. This is a classification and verification task, not a generative one. Smaller, faster models (such as Claude 3 Haiku, GPT-4o-mini, or Gemini 1.5 Flash) are typically sufficient and reduce cost and latency. However, if your required disclaimers involve complex legal language with high semantic variability, test whether a larger model reduces false negatives before committing to the cheaper option. Human review gating should be configured based on the compliance_status field: fully_compliant outputs can proceed automatically; partially_compliant outputs should trigger a review queue with the specific missing or misplaced disclaimers highlighted; non_compliant outputs should block publication and alert the content owner. Never silently discard a non-compliant output—the failure itself is a signal that the generation pipeline may have a systematic issue.

Logging and audit trails are non-negotiable for regulated domains. Every invocation of this prompt should log: the content hash, the required disclaimer set version, the model and model version used, the raw compliance report, the final routing decision (auto-pass, review, block), and the timestamp. This creates an auditable record that a compliance check was performed, which is often a regulatory requirement itself. Tool integration is straightforward: this prompt does not require external tools or retrieval, as all necessary information is passed in the prompt. However, if your disclaimer library is large or version-controlled, consider storing [REQUIRED_DISCLAIMERS] in a configuration service or database and injecting it at runtime rather than hardcoding it in the prompt template. This allows legal teams to update required text without touching application code.

What to avoid: Do not use this prompt as a content generator. It is a verifier. Do not rely on it as the sole compliance check for life-safety, medical device, or securities filing content without human review. Do not skip the output schema validation step—model outputs can drift, and a missing field in the JSON report can crash your pipeline. Finally, test your exact-match tolerance with edge cases: trailing whitespace, smart quotes vs. straight quotes, and line breaks can all cause false negatives that erode trust in the automation.