Policy Boundary Coverage Analysis Prompt Template

This prompt is designed for safety engineers and ML platform teams who need to measure how completely their defined safety policies cover the space of possible harmful or disallowed user requests. The primary job-to-be-done is identifying blind spots: policy categories that are missing, ambiguous, or untested against real-world adversarial inputs. You should use this prompt when you have a set of written policies and a representative sample of production or red-team requests, and you need a structured coverage map that highlights gaps before they become incidents.

The ideal user has access to both the policy documents and a log of user requests or synthetic test cases. Required context includes the full text of the policies, a taxonomy of known harm categories (such as those from MLCommons or internal standards), and a sample of requests that spans compliant, borderline, and violating examples. Do not use this prompt when you lack a defined policy set or when the goal is to evaluate a single request's compliance—that is a classification task, not a coverage analysis. This prompt is also inappropriate for real-time enforcement decisions; it is an offline analytical tool for improving policy completeness.

Before running this analysis, ensure your policy documents are versioned and that the request sample is representative of your production traffic. The output will be most actionable when reviewed by a cross-functional team that includes policy authors, safety engineers, and product owners. Avoid treating the generated coverage map as a final audit artifact without human review—the model can identify structural gaps but cannot assess organizational risk tolerance or legal requirements. After generating the analysis, prioritize gaps by potential harm severity and integrate findings into your policy iteration and regression test suite.

This template is designed to be copied directly into your prompt management system or orchestration code. It accepts a set of defined policies, an optional industry taxonomy for alignment, and a set of representative or adversarial requests. The model's job is to produce a structured coverage map, identify gaps where no policy clearly applies, and flag unaddressed risk categories. Use this template when you are auditing an existing policy suite, preparing for a compliance review, or integrating a new policy into an enforcement pipeline. Do not use this template for real-time enforcement decisions; it is an offline analysis tool.

codeCopy
You are a safety policy analyst. Your task is to measure how completely a set of defined policies covers the space of possible harmful or disallowed requests.

## INPUTS

### DEFINED POLICIES
[POLICIES]

### INDUSTRY TAXONOMY (OPTIONAL)
[TAXONOMY]

### REQUEST SAMPLE
[REQUESTS]

## INSTRUCTIONS

1. For each request in the sample, determine which policy applies. If multiple policies apply, note all of them. If no policy clearly applies, mark it as a coverage gap.
2. Map each policy to the taxonomy categories it addresses, if a taxonomy is provided. Flag any taxonomy categories that have zero associated policies.
3. Identify unaddressed risk categories: types of harmful requests that are not covered by any existing policy but are plausible given the system's domain.
4. For each coverage gap, assign a severity estimate (LOW, MEDIUM, HIGH, CRITICAL) based on potential harm and likelihood of occurrence.

## OUTPUT SCHEMA

Return a valid JSON object with this exact structure:
{
  "coverage_summary": {
    "total_policies": number,
    "total_requests_analyzed": number,
    "covered_requests": number,
    "gap_requests": number,
    "coverage_percentage": number,
    "taxonomy_categories_covered": number,
    "taxonomy_categories_unaddressed": number
  },
  "per_request_analysis": [
    {
      "request_id": "string",
      "request_text": "string",
      "applicable_policies": ["policy_name"],
      "coverage_status": "COVERED | PARTIALLY_COVERED | GAP",
      "gap_severity": "LOW | MEDIUM | HIGH | CRITICAL | N/A",
      "rationale": "string"
    }
  ],
  "taxonomy_alignment": [
    {
      "taxonomy_category": "string",
      "covered_by_policies": ["policy_name"],
      "status": "COVERED | UNCOVERED"
    }
  ],
  "unaddressed_risk_categories": [
    {
      "category_name": "string",
      "description": "string",
      "example_request": "string",
      "severity": "LOW | MEDIUM | HIGH | CRITICAL",
      "recommended_action": "string"
    }
  ],
  "overall_assessment": "string"
}

## CONSTRAINTS

- Do not invent policies. Only use the policies provided in [POLICIES].
- If a request is ambiguous, note the ambiguity in the rationale and assign PARTIALLY_COVERED.
- For gap severity, consider both the potential harm of the unaddressed request and how likely it is to occur in production.
- If no taxonomy is provided, omit the taxonomy_alignment field from the output.
- Be specific in gap descriptions. Vague gap reports are not actionable.

Adaptation notes: Replace [POLICIES] with your actual policy documents or structured policy objects. [TAXONOMY] can be populated with a framework like the MLCommons AI Safety Taxonomy or your internal risk categories; leave it empty if you are not aligning to an external standard. [REQUESTS] should include a mix of known violation types, edge cases from your red-teaming exercises, and benign requests to verify the analysis does not over-flag. For high-risk domains, always have a human safety analyst review the gap report before making enforcement changes. Run this analysis on a recurring schedule—policy coverage degrades as new attack patterns emerge and product surfaces change.

This prompt is not a one-shot report generator; it is an analytical engine that should be embedded in a policy review pipeline. The primary integration point is a scheduled or trigger-based job that runs whenever a policy document is updated, a new threat model is published, or a regulatory framework changes. The harness must supply the prompt with a complete policy document, a taxonomy of known harm categories (aligned to frameworks like MLCommons AI Safety or internal taxonomies), and a set of historical or synthetic adversarial probes. The model's output—a coverage map, gap list, and unaddressed risk categories—should be treated as a structured artifact that feeds into a ticketing system for policy revision, not as a final audit report.

Wire the prompt into an application using a multi-step pipeline. First, a pre-processing step chunks the policy document and extracts enforceable rules using the sibling Policy Boundary Extraction Prompt Template. Second, the coverage analysis prompt receives the extracted rules, the harm taxonomy, and a representative sample of probes. The model should be instructed to output a strict JSON schema with fields for covered_categories, uncovered_categories, ambiguous_boundaries, and gap_severity_scores. Implement a retry loop with a validator that checks for schema compliance, completeness (all taxonomy categories must appear in either covered or uncovered lists), and internal consistency (a category cannot appear in both lists). Log every run with a unique analysis_id, the policy version hash, and the model version for auditability. For high-risk safety systems, route outputs with gap_severity_scores above a defined threshold to a human safety engineer for review before the gap is accepted into the remediation backlog.

Model choice matters here. Use a model with strong reasoning and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro, configured with response_format set to json_schema or the equivalent constrained output mode. Do not rely on a model that frequently skips categories or hallucinates coverage for unaddressed areas. Implement a secondary eval step using the Policy Boundary Edge Case Discovery Prompt Template to generate probes targeting the reported gaps; if the model correctly refuses or handles those probes, the gap may be a false positive, indicating the analysis prompt needs calibration. Avoid running this prompt on every user request—it is a batch analysis tool, not a real-time guardrail. The next step is to feed verified gaps into the Policy-to-Instruction Translation Prompt Template to close the coverage loop.