Compliance Obligation Register Extraction Prompt Template

This prompt is designed for compliance operations teams that need to convert dense, semi-structured obligation registers into machine-readable, structured JSON records. The primary job-to-be-done is the reliable, traceable extraction of regulatory obligations, including their associated controls, deadlines, responsible parties, and evidence requirements. The ideal user is a compliance engineer or GRC platform developer who is building an ingestion pipeline for audit evidence repositories, compliance monitoring systems, or obligation tracking dashboards. The required context is the raw text of an obligation register, which may be a PDF, a spreadsheet export, or a section of a larger regulatory filing. The prompt assumes the input text contains a mapping of regulatory citations to internal controls and is not a free-form policy document.

You should use this prompt when manual extraction is too slow or inconsistent, and when you need to enforce a strict output schema for downstream system integration. It is particularly effective when the obligation register has a repeating structure, such as a table or a series of similarly formatted sections, where each row or block represents a single obligation. The prompt is built to handle explicit missing-field detection, so it is a strong fit for production pipelines where a silent null is worse than an explicit 'MISSING' flag. For example, if a deadline field is blank in the source, the prompt is instructed to output "deadline": "MISSING" rather than omitting the key, which prevents downstream ETL failures.

Do not use this prompt for extracting obligations from free-form legal contracts, policy narratives, or regulatory text that has not already been structured into a register format. It is not a general-purpose legal extraction tool. For those use cases, consider the Contract Clause Isolation and Extraction or the Regulatory Filing Citation Generation playbooks. Additionally, this prompt is not a replacement for a human compliance review; its output should be treated as a draft for acceleration, not a final, audited record. The next step after implementing this prompt is to build a validation harness that checks for obligation completeness, citation format, and deadline logic before the data enters your system of record.

The following prompt template is designed to be placed directly into your system instructions or sent as a user message. It instructs the model to act as a compliance extraction engine, parsing a provided document to produce a structured JSON array of obligations. Each obligation record is grounded with a regulatory citation and includes fields for tracking status, deadlines, and responsible parties. The template uses square-bracket placeholders that you must replace with your specific inputs before sending the request to the model.

textCopy
You are a compliance extraction engine. Your task is to parse the provided compliance obligation register document and extract every distinct obligation into a structured JSON array.

## INPUT
Document: [DOCUMENT_TEXT]

## OUTPUT_SCHEMA
Return a single JSON object with a key "obligations" containing an array of objects. Each object must conform to this schema:
{
  "obligation_id": "string (unique identifier from source or generated as OB-XXX)",
  "obligation_description": "string (concise, actionable description of the requirement)",
  "regulatory_citation": {
    "regulation": "string (e.g., 'GDPR', 'SOX', 'HIPAA')",
    "article_section": "string (e.g., 'Art. 5(1)(f)', 'Section 302')",
    "source_text": "string (verbatim quote from the document supporting this obligation)"
  },
  "responsible_party": "string (role, department, or individual named as owner)",
  "deadline": "string (ISO 8601 date YYYY-MM-DD or 'ongoing' if no fixed date)",
  "status": "string (one of: 'compliant', 'non-compliant', 'in-progress', 'not-assessed')",
  "evidence_required": "string (description of the evidence needed to prove compliance)",
  "risk_level": "string (one of: 'critical', 'high', 'medium', 'low')",
  "confidence": "number (0.0 to 1.0 indicating extraction confidence for this record)"
}

## CONSTRAINTS
- Extract every obligation. Do not skip any.
- If a field's value is not present in the document, use `null` explicitly. Do not guess.
- The `source_text` field must contain a verbatim quote from the document.
- If the document provides no unique obligation ID, generate one using the prefix 'OB-' followed by a three-digit number.
- For `risk_level`, infer from language like 'must', 'critical', 'high priority' if not explicitly stated. Default to 'medium' if unclear.
- Set `confidence` to 1.0 for explicitly stated fields, 0.7 for clearly inferred fields, and 0.5 or lower for ambiguous extractions.

## EXAMPLES
Input: "GDPR Art. 32 requires the CISO to implement encryption at rest by 2025-06-01. Evidence: annual penetration test report."
Output:
{
  "obligation_id": "OB-001",
  "obligation_description": "Implement encryption at rest",
  "regulatory_citation": {
    "regulation": "GDPR",
    "article_section": "Art. 32",
    "source_text": "GDPR Art. 32 requires the CISO to implement encryption at rest by 2025-06-01."
  },
  "responsible_party": "CISO",
  "deadline": "2025-06-01",
  "status": "not-assessed",
  "evidence_required": "Annual penetration test report",
  "risk_level": "high",
  "confidence": 1.0
}

To adapt this template, replace [DOCUMENT_TEXT] with the full text of your obligation register. If your register uses a different risk taxonomy or status vocabulary, update the enum lists in the OUTPUT_SCHEMA and CONSTRAINTS sections. For production use, always pair this prompt with a JSON schema validator in your application layer to catch malformed outputs. In high-stakes compliance workflows, route any record with a confidence score below 0.8 for human review before ingestion into your system of record.

This prompt is designed to be a single step inside a larger compliance document ingestion pipeline. It expects pre-extracted text from an obligation register (PDF, DOCX, or scanned OCR output) and produces a structured JSON array of obligation records. The application layer is responsible for document parsing, text chunking, and post-extraction validation before the output reaches a compliance system of record. Do not send raw binary files to the model; pre-process documents into clean text with page and section markers preserved for citation grounding.

Wire the prompt into an application using a validate → retry → escalate pattern. After the model returns JSON, run a schema validator that checks: (1) every obligation record has a non-null obligation_id, description, regulatory_source, and responsible_party; (2) deadline fields parse as valid dates or explicit null with a deadline_missing_reason populated; (3) evidence_required is a non-empty array when status is active; and (4) every regulatory_citation field contains a document section or paragraph reference, not a vague paraphrase. If validation fails, construct a retry prompt that includes the original text, the partial output, and a structured error report listing exactly which records and fields failed. Limit retries to two attempts before routing to a human review queue. Log every extraction attempt with the model version, prompt hash, input text hash, validation results, and final output for auditability.

For high-risk compliance workflows, insert a human approval gate after successful validation. Route records where risk_classification is high or critical, or where any confidence_score falls below 0.85, to a review interface that displays the extracted obligation side-by-side with the source text snippet. The reviewer confirms, corrects, or rejects each record before it enters the obligation register system. For lower-risk records with high confidence, you can auto-ingest but must still log the extraction provenance. Choose a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 to minimize variability. If using a local or private deployment, ensure the model supports the same JSON schema constraints and test calibration against your validation suite before production cutover.

Do not treat this prompt as a standalone solution. It works best when paired with: (1) a document structure parser that identifies obligation register sections before extraction; (2) a terminology normalization layer that maps variant regulatory references to a canonical taxonomy; and (3) a missing field detector that flags incomplete sections before extraction begins. Avoid wiring the prompt directly to a downstream compliance database without the validation and review gates described above—silent extraction errors in obligation registers create audit exposure and regulatory risk.