Regulatory Filing Evidence Extraction and Ranking Prompt

This prompt is designed for RegTech and compliance product teams that need to extract structured compliance evidence from regulatory filings. It ranks obligations, definitions, and exceptions by applicability, effective date, and penalty severity. The output is a compliance evidence map that distinguishes black-letter law from interpretive guidance. This prompt belongs in a pipeline where human review gates are mandatory for any output labeled as interpretive rather than explicit regulatory text. Use this when your product needs to surface the most actionable regulatory requirements from dense filings, not when you need a general summary or a conversational Q&A interface.

The ideal user is a compliance officer, legal engineer, or product manager building an AI-assisted regulatory intelligence tool. The required context includes the full text of one or more regulatory filings, a defined jurisdiction, and a target compliance domain (e.g., anti-money laundering, data privacy, emissions reporting). The prompt expects a structured output schema with fields for obligation text, source citation, effective date, penalty severity, and a binary classification of 'black-letter' versus 'interpretive.' Without these inputs, the model will produce vague, unranked, or legally unreliable output. The prompt is not suitable for real-time legal advice, contract negotiation, or any workflow where the model's output is shown directly to a regulator without human review.

Do not use this prompt when the regulatory text is highly fragmented across hundreds of documents without a retrieval step. This prompt assumes the relevant filing text is already provided in the context window. If you need to search across a large corpus, pair this prompt with a retrieval-augmented generation (RAG) pipeline that first surfaces candidate passages, then feeds them into this ranking prompt. Also avoid this prompt for regulations that are still in draft or comment period, as the model may treat proposed rules as final. Always implement a human-review gate for any output row tagged as 'interpretive,' and run an eval that checks whether extracted obligations are verbatim matches to source text or model paraphrases. Paraphrased obligations without source grounding should be flagged and re-reviewed before ingestion into a compliance system of record.

This template is designed for RegTech and compliance product teams that need to extract structured obligations, definitions, and exceptions from regulatory filings. It accepts the full text of a regulatory document and a compliance domain context, then outputs a ranked evidence map with applicability, effective dates, and penalty severity. The prompt enforces strict JSON output, requires explicit evidence grounding for every extracted item, and distinguishes between black-letter law and interpretive guidance. Before integrating this into a production pipeline, review the failure modes and evaluation criteria in the full playbook.

textCopy
You are a regulatory compliance evidence extraction system. Your task is to read a regulatory filing and extract obligations, definitions, exceptions, and interpretive guidance. You must produce a structured JSON output that ranks each extracted item by applicability, effective date, and penalty severity. You must distinguish between black-letter law (explicit statutory or regulatory text) and interpretive guidance (agency commentary, examples, or staff views).

## INPUT

[REGULATORY_FILING_TEXT]

## COMPLIANCE DOMAIN

[COMPLIANCE_DOMAIN]

## OUTPUT SCHEMA

Return a single JSON object with the following structure. Do not include any text outside the JSON object.

{
  "filing_metadata": {
    "document_title": "string",
    "issuing_body": "string",
    "publication_date": "YYYY-MM-DD or null",
    "effective_date": "YYYY-MM-DD or null",
    "jurisdiction": "string or null",
    "document_type": "string"
  },
  "extracted_items": [
    {
      "item_id": "string (unique identifier within this extraction)",
      "item_type": "obligation | definition | exception | interpretive_guidance | cross_reference",
      "item_text": "string (verbatim text from the filing)",
      "source_location": "string (section, paragraph, or page reference)",
      "plain_language_summary": "string (one-sentence summary for compliance review)",
      "applicability_scope": {
        "entities": ["string"],
        "activities": ["string"],
        "thresholds": ["string"],
        "exclusions": ["string"]
      },
      "effective_date": "YYYY-MM-DD or null",
      "compliance_deadline": "YYYY-MM-DD or null",
      "penalty_severity": "high | medium | low | none_specified",
      "penalty_description": "string or null",
      "evidence_type": "black_letter_law | interpretive_guidance | preamble | footnote | cross_reference",
      "confidence": "high | medium | low",
      "requires_human_review": true,
      "human_review_reason": "string (explain why human review is needed)",
      "related_item_ids": ["string"]
    }
  ],
  "ranking": {
    "high_priority_items": ["item_id"],
    "medium_priority_items": ["item_id"],
    "low_priority_items": ["item_id"],
    "ranking_rationale": "string (explain the ranking methodology)"
  },
  "gaps_and_uncertainties": [
    {
      "description": "string",
      "impact": "string",
      "recommended_action": "string"
    }
  ],
  "human_review_checklist": [
    "string (specific item for human reviewer to verify)"
  ]
}

## CONSTRAINTS

- Extract every obligation, definition, exception, and piece of interpretive guidance. Do not skip items.
- For every extracted item, include verbatim text from the filing. Do not paraphrase the item_text field.
- Distinguish black-letter law from interpretive guidance in the evidence_type field.
- Assign penalty_severity based on explicit penalty language in the filing. Use "none_specified" if no penalty is mentioned.
- Set requires_human_review to true for every item. This is a high-risk compliance workflow.
- If the filing references other documents without providing full text, flag this in gaps_and_uncertainties.
- If effective dates are ambiguous or conditional, set confidence to "low" and explain in human_review_reason.
- Rank items by: (1) imminent effective dates, (2) high penalty severity, (3) broad applicability scope, (4) black-letter law over interpretive guidance.
- Do not invent obligations, penalties, or dates not present in the filing.
- If the filing text is truncated or incomplete, note this in gaps_and_uncertainties.

## RISK LEVEL

[RISK_LEVEL]

## EXAMPLES

[EXAMPLES]

Adapt this template by replacing the square-bracket placeholders with your specific inputs. [REGULATORY_FILING_TEXT] should contain the full text of the regulatory document, cleaned of scanning artifacts but preserving section structure. [COMPLIANCE_DOMAIN] provides context about the regulatory area (e.g., 'anti-money laundering', 'medical device quality systems', 'environmental emissions reporting') to help the model interpret domain-specific terminology. [RISK_LEVEL] should be set to 'high', 'medium', or 'low' to adjust the strictness of the human-review requirements—for high-risk domains, every item should require human review. [EXAMPLES] should include one or two few-shot examples of correctly extracted and ranked items from similar filings to improve output consistency. If you are processing filings from a specific agency (SEC, FDA, EPA, etc.), include the agency name in the compliance domain to improve terminology recognition.

After copying the template, validate that your input text is complete and that section references are preserved. The output schema is designed to be ingested by a compliance workflow system, so field names and types must be preserved exactly. In production, you should validate the JSON output against this schema before storing results, and every item flagged with requires_human_review: true must be routed to a compliance reviewer queue. Do not remove the human-review requirement for high-risk regulatory workflows—this template is designed for RegTech systems where incorrect extraction can have legal consequences.

This prompt is not a standalone chat interaction. It belongs inside a RegTech pipeline that ingests regulatory filings, extracts structured obligations, and routes interpretive findings for human review before any compliance decision is recorded. The harness must treat the model output as a draft evidence map, not as a final compliance artifact. Every obligation, definition, and exception extracted by the model must be traceable back to a specific passage in the source filing, and the harness should enforce that traceability before the output reaches a downstream system or reviewer.

Wire the prompt as a single step in a multi-stage extraction pipeline. Before calling the model, preprocess the filing to split it into manageable sections with stable section identifiers. For each section, call the model with the prompt template, passing the section text as [FILING_TEXT], the jurisdiction and filing type as [CONTEXT], and the required output schema as [OUTPUT_SCHEMA]. Validate the response immediately: check that every extracted obligation has a non-empty source_passage field, that effective_date parses to a valid date or null, and that penalty_severity is one of the allowed enum values. Reject and retry any response that fails schema validation, up to a maximum of two retries with backoff. Log every validation failure for later prompt debugging.

Route outputs through a human-review gate based on a risk score you compute from the extracted fields. For example, flag any obligation where penalty_severity is 'high' or 'critical', where effective_date is within 30 days, or where the model's interpretive_confidence field is below a threshold you set during evaluation. These flagged items should enter a review queue where a compliance analyst can confirm, edit, or reject the extraction. Items with high confidence and low severity can flow through to automated downstream systems, but the harness must retain the full model output and source passage for audit. Never allow black-letter legal interpretations to bypass human review without explicit legal-team approval and a documented risk acceptance.

For model choice, prefer a model with strong instruction-following and structured output capabilities. If your provider supports strict JSON mode or function calling with a defined schema, use that instead of relying on a free-text [OUTPUT_SCHEMA] instruction. This reduces repair loops. If you must use a model without native JSON mode, add a post-processing repair step that attempts to fix common malformations—unbalanced braces, trailing commas, or unescaped quotes—before retrying. Log repair attempts separately so you can measure how often the prompt produces malformed output and decide whether to refactor the prompt or switch models.

Build eval checks that go beyond schema validation. Create a golden dataset of filings with known obligations, definitions, and exceptions annotated by domain experts. After each prompt change or model upgrade, run the pipeline against this dataset and measure precision and recall at the obligation level. Also measure hallucination rate: how often does the model extract an obligation that has no supporting passage in the source text? If hallucination rate exceeds your risk tolerance, tighten the prompt's grounding instructions or increase the human-review threshold. Do not ship a prompt update without running these evals and comparing results against the previous version.