Human-in-the-Loop Escalation Policy Translation Prompt

This prompt is for AI platform engineers and product teams who need to port a human-in-the-loop (HITL) escalation policy from one model provider to another. The core job is translating a source policy—written for a specific model's instruction format, confidence expression, and tool-use patterns—into a functionally equivalent policy for a target model. You need this when your product runs on multiple models, when you're migrating providers, or when you're deploying the same HITL workflow across different environments. The prompt produces escalation instructions with explicit risk thresholds, confidence calibration rules, and approval requirements adapted to how the target model expresses uncertainty.

Use this prompt when you have a concrete source escalation policy and a known target model family. The source policy should already define what actions require human approval, what risk levels trigger escalation, and how the assistant should communicate uncertainty to users. The prompt works best when you provide the target model's native instruction conventions—for example, how it handles system prompts, whether it uses XML tags or markdown for structure, and how it expresses confidence scores. Do not use this prompt to design an escalation policy from scratch; it assumes you have a working source policy and need to preserve its behavioral intent across model boundaries. The output is not a final production policy—it is a translated draft that requires testing against your escalation consistency benchmarks before deployment.

Before using this prompt, gather your source escalation policy, the target model's system prompt format documentation, and a set of escalation test cases that define correct behavior. After generating the translated policy, run it through your cross-model escalation consistency evals to verify that risk thresholds, approval triggers, and uncertainty communication patterns hold. Pay special attention to how the target model expresses confidence—some models use numeric scores, others use verbal qualifiers, and mismatches here cause silent escalation failures. If your workflow involves regulated or high-risk domains, always include human review of the translated policy before it reaches production.

This template is the core instruction set for translating a human-in-the-loop escalation policy from a source model to a target model. It is designed to be dropped into an AI orchestration layer where the source policy, target model identifier, and risk tolerance are known at runtime. The prompt forces the model to produce a structured output that can be parsed by downstream automation, not a free-text suggestion. Use it when you need to programmatically adapt escalation rules—risk thresholds, confidence calibration, approval requirements, and uncertainty language—to a new model's native behavior patterns.

codeCopy
You are an escalation policy translator for multi-model AI systems. Your task is to adapt a human-in-the-loop escalation policy from a source model to a target model while preserving the intended safety and operational behavior.

## SOURCE POLICY
[SOURCE_ESCALATION_POLICY]

## TARGET MODEL
Model: [TARGET_MODEL_NAME]
Provider: [TARGET_PROVIDER]
Known uncertainty expression patterns: [TARGET_MODEL_UNCERTAINTY_PATTERNS]

## TRANSLATION RULES
1. Map all risk thresholds from the source policy to the target model's confidence scale. If the target model expresses confidence as logprobs, map to that. If it uses verbal expressions, map to calibrated verbal anchors.
2. Preserve every escalation trigger from the source policy. Do not drop triggers. If a trigger cannot be directly expressed on the target model, note it in the `unmapped_triggers` field with a recommended workaround.
3. Adapt approval requirement language to the target model's native instruction-following patterns. Some models require explicit "STOP AND ASK" directives; others respond better to structured output flags.
4. Translate uncertainty disclosure templates to match the target model's tone and verbosity tendencies.
5. Add model-specific anti-hallucination instructions for escalation decisions. If the target model tends to over-confidently proceed, add explicit doubt-injection rules.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "adapted_policy": "The complete escalation policy rewritten for the target model as a single system-prompt-ready string.",
  "threshold_mappings": [
    {
      "source_threshold": "Original threshold description",
      "target_threshold": "Mapped threshold on target model",
      "mapping_rationale": "Why this mapping was chosen"
    }
  ],
  "unmapped_triggers": [
    {
      "trigger": "Trigger that could not be directly mapped",
      "reason": "Why direct mapping failed",
      "recommended_workaround": "Alternative approach"
    }
  ],
  "model_specific_additions": [
    "Instruction added specifically for the target model's known behaviors"
  ],
  "consistency_notes": "Any behavioral differences expected after translation and how to test for them"
}

## CONSTRAINTS
- Do not weaken any safety boundary from the source policy.
- Do not invent new escalation triggers not present in the source policy.
- If the target model cannot support a required escalation pattern, flag it in `unmapped_triggers` rather than silently dropping it.
- Preserve all human approval requirements exactly as specified in the source policy.

Adaptation guidance: Replace [SOURCE_ESCALATION_POLICY] with the full text of the existing escalation policy, including all risk thresholds, approval rules, and uncertainty language. [TARGET_MODEL_UNCERTAINTY_PATTERNS] should contain known behavioral notes about the target model—for example, "Claude Sonnet tends to over-explain uncertainty but rarely refuses without explicit instruction" or "GPT-4o expresses confidence numerically when asked but defaults to assertive prose." If you don't have these patterns documented, run a calibration probe on the target model first. The output JSON is designed to be machine-read by a policy deployment pipeline, so validate the schema before applying the adapted policy to production. Always run the escalation_consistency_benchmark eval suite against the adapted policy before shipping.

This prompt is designed to run as a pre-deployment transformation step, not a runtime call. When your platform supports multiple model providers and you need consistent escalation behavior, you run this prompt once per target model during policy authoring, store the translated policy as a versioned artifact, and load it into the target model's system instructions at runtime. The prompt expects a source escalation policy, a target model identifier, and optional calibration examples. It produces a complete system-prompt-ready escalation block with risk thresholds, confidence calibration notes, and approval requirements adapted to how the target model expresses uncertainty.

Validation and retry logic is critical because the output is a system instruction that will govern production behavior. After generation, validate the output against a schema that checks for required sections: risk_thresholds, confidence_calibration, approval_requirements, and escalation_triggers. Each section must contain non-empty, model-specific instructions. If validation fails, retry with the same prompt but append the validation errors as a [CORRECTION_NOTES] block. Set a maximum of 3 retries. If the output still fails validation after 3 attempts, escalate to a human reviewer and log the full prompt, partial outputs, and validation failures for diagnosis. Do not silently deploy a partially valid escalation policy.

Model choice matters. This prompt works best with models that have strong instruction-following behavior and can reason about behavioral differences across model families. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are suitable. Avoid using small or instruction-weak models for this translation task because the output becomes a system instruction that other models must follow—errors here propagate. For open-weight models, run the prompt on a strong cloud model and deploy the translated output to the local model. Logging and audit trails are essential: store the source policy, target model, generated translation, validation results, and any human review decisions in a versioned policy registry. This creates an audit trail for compliance reviews and makes rollback possible if a translated policy causes unexpected escalation behavior in production.

Human review is mandatory when the source policy contains high-risk escalation triggers such as financial transactions, clinical decisions, safety-critical actions, or legal determinations. Even if validation passes, route the translated policy to a review queue where a human can compare the source intent against the adapted instructions. The review should confirm that risk thresholds haven't drifted, approval requirements haven't been weakened, and confidence calibration notes match the target model's known uncertainty patterns. After human approval, freeze the translated policy version and run the escalation consistency benchmark from the playbook's test suite before promoting to production. Never deploy an unreviewed escalation policy translation to a model that handles high-stakes decisions.