Escalation Criteria Definition Prompt Template

This prompt is for AI platform architects and reliability engineers who need to convert natural-language operational policies into a structured, machine-readable escalation criteria document. The core job-to-be-done is codifying an organization's tribal knowledge about when a system should retry, when it should ask for clarification, and when it must hand off to a human. The ideal user has access to existing runbooks, SLAs, or policy documents and needs a consistent, auditable artifact that can be referenced by downstream automation, such as a retry budget controller or a human-in-the-loop review queue.

Do not use this prompt when the underlying policy is undefined, when the goal is to design the escalation logic from scratch without source material, or when the output will directly gate high-risk actions without human review. The prompt produces a definition document, not an execution decision. It requires a clear [POLICY_DOCUMENT] as input, along with a defined [OUTPUT_SCHEMA] that specifies the required fields for each escalation path, such as trigger conditions, confidence thresholds, retry budgets, and SLA targets. The prompt also benefits from [CONSTRAINTS] that limit the scope, such as 'only define paths for payment failures' or 'exclude paths requiring legal review.'

After generating the structured criteria, you must validate the output for completeness and consistency against the source policy. A common failure mode is the model inventing escalation paths that sound plausible but are not present in the original document. To mitigate this, implement a grounding check that requires each criterion to cite a specific section of the input policy. The next step is to treat this output as a configuration artifact: version it, review it with the operations team, and use it as the source of truth for building the actual escalation logic in your application harness.

This prompt template takes a natural-language policy document, operational context, and risk tolerance parameters to produce a structured escalation criteria specification. The output defines confidence thresholds, escalation paths, SLAs, and decision rules that can be directly implemented in an AI harness. Use this template when you need to codify human-written policies into machine-actionable escalation logic, and avoid it when the policy itself is still under active debate or when the domain requires legal review of the resulting criteria.

textCopy
You are an escalation criteria engineer. Your task is to convert a natural-language policy document into a structured escalation criteria specification that can be implemented in an AI operations harness.

## INPUT

**Policy Document:**
[POLICY_DOCUMENT]

**Operational Context:**
[OPERATIONAL_CONTEXT]

**Risk Tolerance Level:** [RISK_TOLERANCE]

**Retry Budget Constraints:**
[RETRY_BUDGET]

**Available Escalation Paths:**
[ESCALATION_PATHS]

## OUTPUT SCHEMA

Produce a JSON object with the following structure:

```json
{
  "escalation_criteria": [
    {
      "criterion_id": "string",
      "trigger_condition": "string",
      "confidence_threshold": "number between 0 and 1",
      "severity": "low | medium | high | critical",
      "escalation_path": "string matching an available path",
      "sla_minutes": "number",
      "requires_human_review": "boolean",
      "fallback_action": "string",
      "policy_source_reference": "string citing the policy section"
    }
  ],
  "default_escalation_path": "string",
  "retry_budget_allocation": {
    "per_criterion": [
      {
        "criterion_id": "string",
        "max_retries": "number",
        "backoff_strategy": "string"
      }
    ],
    "global_max_retries": "number"
  },
  "completeness_checks": {
    "covered_policy_sections": ["string"],
    "uncovered_policy_sections": ["string"],
    "gaps_identified": ["string"]
  },
  "consistency_notes": ["string"]
}

CONSTRAINTS

[CONSTRAINTS]

EXAMPLES

[EXAMPLES]

INSTRUCTIONS

1. Extract every condition, threshold, or rule from the policy document that implies an escalation decision.
2. For each extracted rule, define a concrete trigger condition with a measurable confidence threshold.
3. Assign severity levels based on the operational impact described in the policy.
4. Map each criterion to exactly one available escalation path.
5. Set SLAs that reflect the urgency implied by the policy language.
6. Flag any criterion where the policy is ambiguous and human review is required.
7. Run completeness checks: list every policy section and confirm whether it produced at least one criterion.
8. Identify consistency issues such as conflicting thresholds, missing paths, or circular escalation logic.
9. If the policy document contains no measurable thresholds, infer reasonable defaults and flag them in consistency_notes.
10. Output only the JSON object. Do not include explanatory text outside the JSON.

Adapt this template by replacing each square-bracket placeholder with concrete values. For [POLICY_DOCUMENT], provide the full text of the policy you want to codify. For [OPERATIONAL_CONTEXT], describe the system, its users, and the types of requests it handles. [RISK_TOLERANCE] should be a label like low, medium, or high that influences threshold strictness. [RETRY_BUDGET] defines how many total retries are available across the system. [ESCALATION_PATHS] should list the concrete paths available, such as human_review_queue, senior_analyst_escalation, automated_retry, or abort. Use [CONSTRAINTS] to add domain-specific rules like regulatory requirements, and [EXAMPLES] to provide few-shot demonstrations of correctly structured criteria. After generating the output, validate the JSON schema, check that every criterion references a real escalation path, and confirm that completeness_checks accurately reflect the policy document's coverage. For high-risk domains, always route the output through human review before deploying the criteria to production.

This prompt is not a one-off document generator; it is a policy-to-configuration compiler. The implementation harness should treat the prompt as a deterministic transformation step that converts natural-language policies, risk matrices, and operational constraints into a structured escalation criteria document. The harness must validate that the output is complete, internally consistent, and actionable before it is committed to any runbook, routing engine, or review queue configuration. Because escalation criteria directly govern when AI systems stop, retry, or hand off to humans, the harness must enforce strict schema validation and flag any ambiguity that could cause production misrouting.

Wire the prompt into a policy ingestion pipeline: accept a policy document, a risk tolerance profile, and a list of available escalation paths as inputs. Before calling the model, pre-process the policy document to extract relevant sections (e.g., severity definitions, response time commitments, regulatory requirements) and inject them into the [POLICY_DOCUMENT] placeholder. After receiving the model output, run a multi-stage validation pass. First, validate the JSON schema against a predefined escalation criteria schema that requires fields like trigger_conditions, confidence_thresholds, escalation_paths, sla_timers, and fallback_actions. Second, run a completeness check: every escalation path defined in the input must appear in the output, and every trigger condition must map to at least one path. Third, run a consistency check: no two trigger conditions should map to conflicting paths for the same input state, and all confidence thresholds must be within valid ranges (0.0 to 1.0). If any validation fails, log the specific failure, append it to the retry context, and re-invoke the prompt with the error details in a [PREVIOUS_ERRORS] placeholder. Cap retries at three attempts before escalating the policy-to-criteria compilation failure to a human reviewer.

For high-risk domains such as healthcare, finance, or safety-critical operations, never auto-apply the generated criteria to production routing without human approval. The harness should produce a diff view comparing the new criteria against the currently deployed criteria, highlighting additions, removals, and threshold changes. Route this diff to a review queue with a structured approval payload that includes the original policy document, the generated criteria, the diff, and any validation warnings. Only after explicit human sign-off should the criteria be deployed to the routing engine or agent harness. Log every compilation attempt, validation result, and approval decision for audit trails. Avoid the temptation to treat this as a fire-and-forget prompt; stale escalation criteria are a latent production risk, so schedule periodic re-compilation whenever source policies change.