Approval Matrix Extraction Prompt Template

This prompt is designed for compliance engineers, platform teams, and automation architects who need to translate organizational policy documents, standard operating procedures (SOPs), and runbooks into a machine-readable approval matrix. The core job is to extract structured rules that define who must approve what, under which conditions, and in what sequence. The ideal user is someone encoding governance into an AI workflow or an internal tool, where hardcoding every approval path in application code is brittle and expensive to maintain. The prompt expects a source document as input and produces a structured schema of roles, thresholds, conditions, and sequencing rules that can be consumed by a downstream approval engine.

This prompt is appropriate when you have a static or semi-static policy document and you need to bootstrap an approval system quickly. It works best on documents with explicit conditional language, such as 'Managers must approve purchases over $10,000' or 'Legal review is required for all third-party data sharing agreements.' It is not a replacement for a full legal review of the extracted rules, nor is it designed for ambiguous, contradictory, or purely principle-based policies that lack concrete triggers. Do not use this prompt for real-time interpretation of novel situations; it is an extraction and structuring tool, not a reasoning agent for edge cases. The output is a starting point for implementation, not a final compliance artifact.

Before using this prompt, ensure you have a clean, text-based version of the source document. Scanned PDFs or images must be pre-processed with OCR. The prompt includes placeholders for [POLICY_DOCUMENT], [OUTPUT_SCHEMA], and [CONSTRAINTS], which you must populate with your specific schema requirements and any domain-specific rules, such as regulatory jurisdictions or internal role taxonomies. The next step after extraction is to run the provided eval checks for completeness against the source text and for conflict detection between extracted rules. A human reviewer must always validate the matrix against the original document before it is loaded into any system that gates real-world actions.

The following prompt template is designed to be dropped into your AI workflow. It takes a source document and a defined output schema, then extracts approval rules into a machine-readable matrix. The template uses square-bracket placeholders for all dynamic inputs, allowing you to swap in different policies, schemas, and constraints without rewriting the core instruction.

textCopy
You are an expert compliance engineer. Your task is to read the provided policy document and extract all approval rules into a structured matrix.

## INPUT
Document:
"""
[DOCUMENT_TEXT]
"""

## OUTPUT SCHEMA
Return a single JSON object with a key "approval_matrix" containing an array of rule objects. Each rule object must have the following fields:
- "rule_id": string (a unique identifier for the rule, e.g., "APR-001")
- "action": string (the action requiring approval, e.g., "production_deployment", "data_deletion")
- "condition": string (the triggering condition, e.g., "amount > $10,000", "environment == 'prod'")
- "required_approvers": array of objects, each with:
    - "role": string (the role title, e.g., "VP of Engineering")
    - "type": string ("required" | "advisory" | "veto")
    - "quorum": integer or null (minimum number of approvers from this role, null if not applicable)
- "sequence": array of strings (ordered list of role titles defining the approval chain, empty if parallel)
- "timeout_hours": integer or null (escalation timeout, null if no timeout)
- "escalation_role": string or null (role to escalate to on timeout)
- "source_text": string (the exact sentence or paragraph from the document that defines this rule)

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Extract every approval rule explicitly stated in the document.
2. Do not infer rules that are not directly supported by the source text.
3. If a rule is ambiguous or missing required details (e.g., a role is mentioned but not its authority type), include it but set the ambiguous field to null and add a note in a "warnings" array at the top level of the JSON output.
4. The "source_text" field must contain a verbatim quote from the document.
5. If the document contains no approval rules, return an empty "approval_matrix" array.

To adapt this template, replace the placeholders with your specific context. For [CONSTRAINTS], add any domain-specific rules like "Ignore rules related to office supply purchases" or "Only extract rules for the 'production' environment." For [EXAMPLES], provide one or two few-shot examples of correctly formatted rules from a similar document to guide the model's output style. Always pair this prompt with a post-processing validation step that checks the JSON schema, verifies that every source_text quote exists in the original document, and flags any rules with null required fields for human review before the matrix is used in an automated approval system.

Integrating the Approval Matrix Extraction prompt into a production system requires treating the LLM call as one step in a deterministic pipeline, not as a standalone function. The core job is to convert unstructured policy text into a structured, machine-readable matrix. The implementation harness must therefore handle input preparation, model invocation, output validation, conflict detection, and integration with downstream policy engines. This prompt is high-stakes because incorrect extraction can lead to unauthorized actions or audit failures, so the harness must include strong validation and human review gates before the extracted matrix is used to gate real operations.

Begin by assembling the input context. The [POLICY_DOCUMENT] placeholder should be populated with the full text of the source SOP, runbook, or policy document. If the document is long, pre-process it by chunking into logical sections (e.g., by heading) and running extraction on each chunk, then merging the results. The [OUTPUT_SCHEMA] placeholder must be replaced with a strict JSON Schema definition that specifies the exact shape of the approval matrix: an array of rules, each containing fields like action_type, conditions (an object with risk_tier, dollar_threshold, data_sensitivity), required_approvers (an ordered array of role objects with role, sequence_order, is_veto_holder), and policy_source (a string quoting the exact sentence from the source). The [CONSTRAINTS] placeholder should enforce that every extracted rule must cite its source text verbatim and that no rule should be invented if not explicitly stated. After the model returns a response, do not trust it. Run a validation layer that parses the JSON output and checks it against the schema. If parsing fails, use a repair prompt from the Output Repair and Validation Prompts pillar to fix malformed JSON, but limit retries to 3 attempts before escalating to a human.

The most critical post-extraction step is conflict detection and completeness verification. Implement an eval harness that compares the extracted rules against a set of expected rules derived from a golden dataset of policy documents. For each extracted rule, verify that the policy_source citation exists in the original document using a substring match or fuzzy search. Then, run a conflict detection pass: group rules by action_type and check for overlapping conditions with different approver lists. For example, if one rule says 'transfers over $10k need VP approval' and another says 'transfers over $5k need Director approval,' flag this for human review. Log every extraction with the model version, prompt template hash, input document hash, raw output, validated output, and conflict flags. This audit trail is non-negotiable for governance. Finally, integrate the validated matrix into your approval routing system by converting it into a decision function that, given an action and its context, returns the ordered list of required approvers. Never allow the LLM to make the final routing decision at runtime; the extracted matrix should be reviewed, approved, and loaded as a static configuration that your application code evaluates deterministically.

For model choice, prefer a model with strong structured output capabilities and a large context window if processing long documents. Use low temperature (0.0–0.1) to maximize determinism. Implement a human-in-the-loop review step where a compliance engineer or platform owner must approve the extracted matrix before it goes live. The review interface should display each rule side-by-side with its source text, highlight conflicts, and require explicit signoff. After deployment, monitor for drift: if the source policy document changes, trigger a re-extraction and re-review cycle automatically. Avoid wiring the raw LLM output directly to any system that executes actions; the approval matrix is a policy artifact that must be treated with the same change management rigor as application code.