Classification Label Correction Prompt

This prompt is a secondary repair step for production triage and routing systems where a primary classifier produces outputs that fail downstream validation. You should use it when your existing classification pipeline assigns wrong labels, inconsistent confidence scores, or conflicting multi-label sets that break routing decisions. The prompt works by presenting few-shot corrective examples that teach the model how to repair classification errors—showing boundary cases where labels overlap, hierarchy constraints where parent-child relationships must be respected, and confidence recalibration patterns where scores need adjustment based on evidence strength. This is not a replacement for your primary classifier. It is a targeted correction layer that sits between classification output and routing execution, reducing the number of retry loops and improving self-correction accuracy in production workflows.

Concrete scenarios where this prompt adds value include: when label distributions drift from expected patterns and your primary classifier starts over-assigning a minority category; when multi-label outputs contain mutually exclusive combinations that violate business rules (e.g., 'refund' and 'new_purchase' on the same ticket); when confidence scores are miscalibrated and high-confidence predictions fail downstream checks; and when you need a secondary correction layer before routing decisions execute against queues, teams, or escalation paths. The prompt requires you to provide the original classification output, the input text that was classified, your label taxonomy with hierarchy constraints, and a set of corrective examples that demonstrate the repair patterns you want the model to learn. Without these inputs, the model cannot perform reliable correction.

Do not use this prompt as your primary classifier—it is designed for repair, not initial classification, and will underperform on novel inputs without a first-pass label to correct. Do not use it when your primary classifier's error rate exceeds 30-40%, as the correction layer will amplify rather than fix systemic failures. In high-risk domains such as healthcare triage, legal routing, or financial compliance, always route corrected outputs through human review before execution, and log both the original and corrected labels for audit trails. Before deploying this prompt to production, run it against a golden dataset of known classification errors and measure correction accuracy, over-correction rate (fixing correct labels), and downstream routing improvement. If correction accuracy falls below your threshold, invest in improving your primary classifier or expanding your corrective example set before relying on this repair layer.

This prompt template is designed to be copied directly into your prompt management system or orchestration layer. It accepts a previously classified input along with its problematic labels and confidence scores, then produces a corrected classification by reasoning through boundary cases, hierarchy constraints, and confidence recalibration. The template uses square-bracket placeholders that you must replace with production data before execution. Each placeholder maps to a specific input source in your classification pipeline: the original input text, the model's raw classification output, your label taxonomy, and a curated set of corrective examples that demonstrate the desired repair behavior.

textCopy
You are a classification correction system. Your task is to review a previous classification output, identify errors in label assignment, confidence scoring, and hierarchy compliance, then produce a corrected classification.

## TAXONOMY
[TAXONOMY]

## CORRECTIVE EXAMPLES
These examples show common classification errors and their corrections. Study the pattern of fixes applied.

[EXAMPLES]

## INPUT TO CORRECT
**Original Text:** [INPUT_TEXT]

**Previous Classification:**
[PREVIOUS_CLASSIFICATION]

## CORRECTION RULES
1. Labels must match the taxonomy exactly. Correct near-miss variants, synonyms, and case errors to canonical labels.
2. If the previous classification assigns labels that violate hierarchy constraints (e.g., parent and child labels that are mutually exclusive per the taxonomy), resolve the conflict by selecting the most specific applicable label.
3. Recalibrate confidence scores to reflect genuine uncertainty. Overconfident scores (0.95+ on ambiguous cases) should be reduced. Scores should reflect the difficulty of the classification decision.
4. If multi-label output is allowed per the taxonomy, ensure label sets are non-redundant and non-contradictory.
5. If the input text is ambiguous or insufficient for confident classification, reduce confidence scores and flag uncertainty rather than guessing.
6. Do not introduce labels that do not exist in the provided taxonomy.

## OUTPUT FORMAT
Return a JSON object with this exact structure:
{
  "corrected_labels": [
    {
      "label": "<canonical label from taxonomy>",
      "confidence": <float between 0.0 and 1.0>,
      "correction_reason": "<brief explanation of what was fixed and why>"
    }
  ],
  "correction_summary": "<one-sentence summary of all corrections applied>",
  "uncertainty_flags": ["<list any uncertainty concerns, empty array if none>"]
}

To adapt this template for your production system, replace each bracketed placeholder with live data from your pipeline. [TAXONOMY] should contain your full label hierarchy with parent-child relationships and mutual exclusion rules clearly stated. [EXAMPLES] is the most critical section: populate it with 3-6 input-classification-correction triples that demonstrate the specific failure modes you observe in production, such as near-miss label variants, hierarchy violations, and overconfident scores on ambiguous inputs. [INPUT_TEXT] receives the original user query or document that was classified. [PREVIOUS_CLASSIFICATION] receives the raw output from your primary classifier, including any malformed labels, incorrect confidence scores, or conflicting multi-label sets. The output schema is fixed; do not modify the JSON structure without also updating your downstream validation logic. Before deploying, test this prompt against a golden set of known classification errors and measure whether corrected labels match expected corrections, confidence scores become better calibrated, and hierarchy violations are resolved correctly.

The Classification Label Correction Prompt is designed to sit inside a post-classification repair loop, not as the primary classifier. After your initial classification model (or prompt) assigns labels, confidence scores, or multi-label sets, this prompt receives the original input, the initial classification, and any validation errors or constraint violations. Its job is to produce a corrected label set that satisfies hierarchy constraints, resolves conflicts, and recalibrates confidence. Wire it as a synchronous repair step before the label is committed to downstream routing, queuing, or analytics systems.

Build the harness with three guard layers. First, validate the corrected output against your label taxonomy: check that every returned label exists in the allowed set, that hierarchical constraints are satisfied (e.g., a subcategory cannot appear without its parent), and that confidence values fall within [0,1] and sum appropriately for multi-label outputs. Second, implement a retry budget—start with a maximum of two correction attempts. If the first correction still fails validation, feed the specific validation error messages back into the prompt's [VALIDATION_ERRORS] placeholder and retry once. Third, if both attempts fail, escalate to a human review queue rather than silently accepting a broken label. Log the original input, initial classification, both correction attempts, and validation failures for later analysis. This log becomes your dataset for improving the correction examples over time.

For model choice, prefer a model with strong instruction-following and structured output capability (GPT-4o, Claude 3.5 Sonnet, or equivalent). The prompt relies on few-shot examples to demonstrate label correction patterns, so choose a model that attends well to examples in context. Set temperature low (0.0–0.2) to reduce variance in label selection and confidence values. If your taxonomy is large, consider retrieving only the relevant subset of the label hierarchy (the initially predicted labels plus their siblings and parents) rather than including the full taxonomy in every call—this reduces token cost and prevents the model from being distracted by irrelevant categories. Use a simple in-memory cache or vector lookup keyed on the initial predicted labels to fetch the relevant taxonomy slice.

The output schema should be strict and machine-parseable. Require JSON with fields: corrected_labels (array of label objects with label, confidence, and optional parent_label), correction_rationale (a short string explaining what was changed and why), and requires_human_review (boolean, set to true if the model is uncertain or if the correction involves a high-stakes label change). Parse this output and run it through your taxonomy validator before accepting it. If requires_human_review is true, bypass the retry loop entirely and send directly to the review queue. This gives the model an explicit escape hatch for ambiguous cases.

For evaluation, build a correction accuracy test harness using a golden dataset of intentionally misclassified examples paired with their known correct labels. Measure: (1) label accuracy—does the corrected label set match the ground truth? (2) constraint compliance—does the output satisfy all hierarchy and taxonomy rules? (3) correction rate—what percentage of errors were successfully fixed vs. escalated? (4) over-correction rate—how often did the prompt change a correct label to an incorrect one? Run this eval suite before deploying any change to the prompt's examples or instructions. Track these metrics over time to detect example drift as your production data distribution shifts.

Avoid wiring this prompt directly in front of users without the validation and escalation layers described above. A raw corrected label with no audit trail is dangerous in routing and triage systems where misclassification can send work to the wrong team, delay critical issues, or violate compliance rules. The harness is what makes the prompt production-grade—the prompt itself is just one component in a reliable correction pipeline.