Regulatory Document Section Completeness Check Prompt

This prompt is for compliance officers, legal operations teams, and regulatory filing managers who need to verify that a generated or drafted regulatory document contains every required section, in the correct order, with all mandatory statements present. The job-to-be-done is reducing the risk of a filing rejection, audit finding, or enforcement action caused by an incomplete submission. The ideal user has a jurisdiction-specific template or checklist (such as an SEC filing requirement, FDA submission structure, or GDPR documentation standard) and needs to compare a candidate document against that template programmatically before human sign-off. The required context includes the full candidate document text and a structured representation of the required sections, their expected ordering, and any mandatory boilerplate statements that must appear verbatim or in substance.

Do not use this prompt when you need legal advice, interpretation of regulations, or a judgment on whether the content of a section is substantively correct. This prompt checks for structural completeness and statement presence, not legal sufficiency. It is also inappropriate for documents where the required structure is ambiguous, unwritten, or based on evolving guidance that cannot be expressed as a deterministic checklist. If the document type requires subjective completeness assessment—such as a narrative policy justification where section boundaries are fluid—use a human review workflow instead. For high-risk filings, always pair this automated check with a qualified human reviewer who can assess substantive accuracy and regulatory nuance. The prompt is a safety net, not a replacement for domain expertise.

After running this prompt, the reader should integrate the structured completeness report into a compliance workflow: flag missing sections for immediate remediation, log ordering violations for template updates, and route documents with mandatory-statement failures for human review. Avoid treating a 'complete' result as a clean bill of health—this prompt does not validate the accuracy of the content within each section. The next step is to combine this structural check with content-level review prompts, such as fact-checking against source evidence or tone and disclaimer compliance verification, before finalizing any regulated submission.

The prompt below is designed to be copied directly into your AI harness. It instructs the model to act as a compliance completeness checker, comparing a generated or drafted regulatory document against a jurisdiction-specific template. All dynamic inputs are represented as square-bracket placeholders—replace these with your actual document text, required section list, and evaluation parameters before execution. The prompt enforces a structured JSON output so that downstream systems can parse the completeness report programmatically.

textCopy
You are a regulatory document completeness auditor. Your task is to compare the provided [DOCUMENT] against the required section template for [JURISDICTION] filings under [REGULATION_NAME].

## Required Sections and Statements
[REQUIRED_SECTIONS]

## Evaluation Instructions
1. Check whether each required section is present in the document. A section is considered present if its heading or content substantively matches the required title or purpose, even if the exact wording differs.
2. For each required section, verify that any mandatory statements, disclosures, or boilerplate language listed in [REQUIRED_STATEMENTS] appear within that section.
3. Check that sections appear in the order specified by [SECTION_ORDER]. Flag any ordering violations.
4. If [CHECK_CROSS_REFERENCES] is true, verify that any internal cross-references (e.g., "see Section 4.2") point to sections that actually exist in the document.

## Output Schema
Return a JSON object with the following structure:
{
  "document_id": "[DOCUMENT_ID]",
  "jurisdiction": "[JURISDICTION]",
  "regulation": "[REGULATION_NAME]",
  "overall_complete": boolean,
  "sections": [
    {
      "required_section": string,
      "present": boolean,
      "heading_match": string | null,
      "missing_statements": [string],
      "ordering_correct": boolean | null,
      "notes": string
    }
  ],
  "ordering_violations": [
    {
      "expected_order": [string],
      "actual_order": [string],
      "description": string
    }
  ],
  "cross_reference_issues": [
    {
      "reference_text": string,
      "target_section": string,
      "target_exists": boolean,
      "location_in_document": string
    }
  ],
  "summary": string
}

## Constraints
- Do not evaluate the legal sufficiency or quality of the content. Only check for presence, ordering, and structural completeness.
- If a section is present but under a different heading, note the actual heading in `heading_match` and set `present` to true.
- If [STRICT_MODE] is true, flag near-matches as missing and require exact heading text.
- Flag any required statement that is entirely absent. Do not flag statements that are present but paraphrased unless [REQUIRE_EXACT_STATEMENT_TEXT] is true.
- If the document contains sections not in the required list, note them in `notes` but do not treat them as violations.
- Base all findings strictly on the provided document text and required sections. Do not infer missing content from external knowledge.

## Risk Level
[RISK_LEVEL]

To adapt this template, start by defining your [REQUIRED_SECTIONS] as a structured list—ideally pulled from a jurisdiction-specific template database rather than hardcoded. The [REQUIRED_STATEMENTS] field should contain exact boilerplate text or semantic descriptions of mandatory disclosures. Set [STRICT_MODE] to true for high-risk filings where regulatory reviewers expect precise heading language; use false when substantive coverage matters more than exact wording. The [RISK_LEVEL] parameter should drive downstream behavior: at high risk levels, any overall_complete: false result should block submission and trigger human review. Before deploying, test this prompt against a golden dataset of known-complete and known-incomplete filings to calibrate your heading_match tolerance and statement-matching behavior.

This prompt is designed to operate as a deterministic gate inside a compliance document generation or review pipeline. It should not be exposed directly to end users. Instead, embed it in an application layer that: (1) loads the target regulatory document text, (2) loads the jurisdiction-specific section template and required-statement list, (3) invokes the model, (4) validates the structured output, and (5) routes the result to the appropriate downstream action—approval, revision, or human review. The prompt itself is stateless; all context must be supplied in [DOCUMENT], [SECTION_TEMPLATE], and [REQUIRED_STATEMENTS].

Model choice and invocation pattern: Use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature=0 to maximize deterministic section detection. Request JSON output with a defined schema—do not rely on parsing free text. Implement a wrapper function that: (a) validates the JSON against the expected schema (fields: sections_found, sections_missing, ordering_issues, required_statement_flags, overall_completeness_score), (b) retries once with the same prompt if validation fails, and (c) escalates to a human review queue if the second attempt also fails or if overall_completeness_score falls below a configurable threshold (e.g., 0.85). Log every invocation with document hash, template version, model response, validation result, and final disposition for auditability.

Jurisdiction template management: Maintain [SECTION_TEMPLATE] and [REQUIRED_STATEMENTS] as versioned configuration files (YAML or JSON) in your repository, not hardcoded in the prompt. Each template should include: jurisdiction, effective_date, required_sections (ordered list with section_id, section_name, required_keywords), and required_statements (list of strings or regex patterns that must appear verbatim or within semantic tolerance). When a regulation changes, update the template, bump the version, and run a regression suite of known-compliant and known-noncompliant documents to confirm the prompt still behaves correctly. Do not rely on the model to know current regulations—always supply the authoritative template as context.

Failure modes and guardrails: The most common production failures are: (1) the model hallucinates section names not present in the document, (2) it misses sections that use variant headings (e.g., 'Risk Factors' vs. 'Risk Disclosures'), (3) it flags a required statement as missing when the statement appears with minor wording differences, and (4) it produces malformed JSON under long documents. Mitigate these by: including a [FUZZY_MATCHING_EXAMPLES] block in the prompt with 2–3 examples of heading variants and acceptable statement paraphrases; implementing a post-processing step that re-scans the document for flagged-missing statements using substring or embedding-based similarity before finalizing the report; and chunking documents longer than the model's context window by section, running the check per-section, then merging results. Always include a human review gate for any document where sections_missing is non-empty or overall_completeness_score < 1.0 before the filing is submitted.