Human Approval Threshold Modification Prompt

This prompt is for human-in-the-loop system designers and prompt engineers who are modifying the approval or escalation criteria inside a production prompt. Before you ship a threshold change, you need to understand the blast radius: how many more items will queue for human review, how many false escalations you will introduce, and how many genuine approvals you risk missing. The prompt takes your current and proposed threshold definitions, a representative sample of decision cases, and produces a structured threshold-sensitivity analysis with expected review-rate change, false-escalation estimates, and missed-approval risks.

Use this when you are changing numeric thresholds, confidence-score cutoffs, risk-tier mappings, or conditional escalation rules in any prompt that gates human review. The prompt expects you to supply the exact before-and-after threshold logic, a labeled sample of cases with ground-truth approval decisions, and the current review-rate baseline. It returns a structured report that includes a confusion matrix shift, a review-volume delta, and a breakdown of cases that flip from auto-approve to escalate (and vice versa). This output is designed to feed directly into a release-gate decision: if the false-escalation rate exceeds your team's review capacity or the missed-approval risk violates your safety SLA, the change should be blocked or revised.

Do not use this prompt for general prompt rewrites that do not touch approval logic, or for systems where approval criteria live entirely in application code rather than in the prompt itself. It is not a substitute for end-to-end integration tests, nor does it assess downstream effects beyond the approval gate. If your threshold logic spans multiple prompts, tool calls, or external rule engines, you need a broader blast-radius analysis before relying on this prompt's output. After running the analysis, pair the results with a canary deployment and a human review of the flipped cases before promoting the change to production.

This prompt template is designed for human-in-the-loop system designers who need to quantify the impact of modifying escalation or approval criteria before deploying a change. It takes the current and proposed threshold descriptions, a representative sample of decision cases, and the risk tolerance of the workflow, then produces a structured sensitivity analysis. The output includes expected review-rate change, false-positive and false-negative risk shifts, and a recommendation on whether the threshold change is safe to proceed.

codeCopy
You are a human-in-the-loop threshold analyst. Your task is to evaluate the impact of changing the approval threshold criteria in an AI-assisted decision system.

## CURRENT THRESHOLD CRITERIA
[CURRENT_CRITERIA]

## PROPOSED THRESHOLD CRITERIA
[PROPOSED_CRITERIA]

## DECISION CASES FOR ANALYSIS
[DECISION_CASES]

## WORKFLOW CONTEXT
- Domain: [DOMAIN]
- Risk Level: [RISK_LEVEL]
- Cost of False Approval: [FALSE_APPROVAL_COST]
- Cost of False Escalation: [FALSE_ESCALATION_COST]
- Current Review Rate: [CURRENT_REVIEW_RATE]
- Target Review Rate (if any): [TARGET_REVIEW_RATE]

## OUTPUT SCHEMA
Produce a JSON object with the following structure:
{
  "threshold_comparison": {
    "current_criteria_summary": "string",
    "proposed_criteria_summary": "string",
    "key_differences": ["string"]
  },
  "impact_analysis": {
    "estimated_review_rate_change": {
      "current_estimated_rate": number,
      "proposed_estimated_rate": number,
      "absolute_change_percentage": number,
      "direction": "increase" | "decrease" | "no_change"
    },
    "false_escalation_risk": {
      "current_risk": "low" | "medium" | "high" | "critical",
      "proposed_risk": "low" | "medium" | "high" | "critical",
      "change_description": "string"
    },
    "missed_approval_risk": {
      "current_risk": "low" | "medium" | "high" | "critical",
      "proposed_risk": "low" | "medium" | "high" | "critical",
      "change_description": "string"
    }
  },
  "case_by_case_analysis": [
    {
      "case_id": "string",
      "current_decision": "approve" | "escalate" | "unclear",
      "proposed_decision": "approve" | "escalate" | "unclear",
      "decision_change": boolean,
      "risk_flag": "none" | "false_positive_risk" | "false_negative_risk",
      "rationale": "string"
    }
  ],
  "edge_cases_identified": [
    {
      "description": "string",
      "why_threshold_ambiguous": "string",
      "recommended_handling": "string"
    }
  ],
  "recommendation": {
    "proceed": boolean,
    "confidence": "low" | "medium" | "high",
    "conditions": ["string"],
    "rollback_triggers": ["string"]
  }
}

## CONSTRAINTS
- Base all estimates on the provided decision cases, not external assumptions.
- Flag any case where the threshold is ambiguous rather than forcing a binary decision.
- If the proposed threshold introduces unacceptable risk for the stated risk level, recommend against proceeding.
- Include specific, measurable rollback triggers in the recommendation.
- Do not invent cases or risks not supported by the provided data.

To adapt this template, replace each square-bracket placeholder with your actual values. [CURRENT_CRITERIA] and [PROPOSED_CRITERIA] should contain the exact threshold descriptions as they appear in your system prompt or policy document. [DECISION_CASES] must include a representative sample of at least 20–50 real or synthetic cases spanning clear-approve, clear-escalate, and boundary scenarios. The [RISK_LEVEL], [FALSE_APPROVAL_COST], and [FALSE_ESCALATION_COST] fields are critical for calibrating the recommendation—be specific about the operational or regulatory consequences of each failure mode. If you lack a [TARGET_REVIEW_RATE], set it to null and the analysis will treat the current rate as the baseline without a directional goal.

Before running this prompt in a production change-review workflow, validate the output against a human-labeled subset of your decision cases. Compare the model's case-by-case classifications to ground-truth labels and measure agreement on decision-change flags. If agreement drops below 90% on boundary cases, refine the threshold descriptions or add more examples before trusting the impact analysis. For high-risk domains such as healthcare, finance, or safety systems, always require human review of the full analysis before approving any threshold modification.

This prompt is designed to operate as a pre-commit analysis tool in a prompt change management pipeline, not as a runtime decision engine. The implementation harness should treat it as a specialized evaluator that receives a diff between two prompt versions and returns a structured sensitivity report. The primary integration point is a CI/CD or change-request workflow where a prompt engineer proposes a modification to escalation or approval criteria, and the system must produce an impact assessment before the change can be merged or deployed. The harness must enforce that the prompt never executes autonomously—its output is always reviewed by a human who owns the approval threshold configuration.

Integration pattern: Wire the prompt into a change-analysis service that accepts three inputs: the current prompt version, the proposed prompt version, and a representative sample of historical inputs that previously triggered or bypassed human review. The service should call the prompt with these inputs and parse the structured JSON output containing threshold_sensitivity_score, expected_review_rate_change, false_escalation_risk, missed_approval_risk, and affected_workflow_segments. Validation layer: Before the output reaches a human reviewer, run automated checks: confirm the JSON schema matches the expected contract, verify that expected_review_rate_change is a numeric value within a reasonable range (e.g., -100% to +1000%), and flag any report where false_escalation_risk or missed_approval_risk exceeds a configurable threshold (e.g., high or critical). If validation fails, block the change and log the failure with the raw prompt output for debugging. Retry logic: If the model returns malformed JSON, retry once with a repair prompt that includes the original output and a schema reminder. If the second attempt fails, escalate to a human with the raw output attached.

Model selection and tool use: This prompt benefits from models with strong instruction-following and structured output capabilities. Use a model that supports strict JSON mode or function calling to enforce the output schema. Do not wire this prompt into a RAG pipeline—it operates on the provided prompt diffs and sample inputs alone. Logging and audit trail: Every invocation must log the input diff, the sample inputs used, the raw model output, the parsed sensitivity report, and the human reviewer's decision (approved, rejected, or modified). Store these records alongside the prompt version history so that future audits can trace why a threshold was changed and what analysis supported the decision. Human review gate: The harness must present the sensitivity report in a review interface that highlights risks above threshold, shows the expected review-volume delta, and requires explicit sign-off before the prompt change can proceed to staging or production. Do not allow automated promotion based solely on the prompt's output—human judgment is required because approval thresholds directly affect operational risk, user experience, and compliance posture.