Extra Hallucinated Field Removal Prompt Template

This prompt is for API developers and integration engineers who receive model outputs containing invented fields not present in the target schema. The job-to-be-done is stripping extra fields that have no source grounding while preserving legitimate data and logging removals for observability. Use this when your model consistently adds plausible-sounding but unsupported fields—like inventing a customer_since date when only name and email were requested—and you need a programmatic cleanup step before the payload hits a database, API gateway, or user-facing surface.

This prompt is not a schema validator or a type coercion tool. It assumes the input is structurally valid JSON and that you have a defined target schema to compare against. Do not use this prompt when the model output is malformed JSON (use the JSON Structure Repair Prompt Template instead), when required fields are missing (use Missing Required Field Injection), or when field names are semantically correct but use wrong casing or near-miss labels (use Wrong Field Name Mapping). This prompt is specifically for removing fields that should not exist at all in the output.

The ideal user has a target schema—either as a JSON Schema document, a list of allowed field names, or a reference object—and needs a reliable, logged, and evaluable removal step. Before deploying this prompt, ensure you have a way to diff the input and output to confirm that only hallucinated fields were removed and that no legitimate fields were stripped. In high-stakes pipelines where false-positive removal could drop critical data, route uncertain cases to a human review queue rather than silently deleting fields.

This template is designed to be copied directly into your application code or prompt management system. It instructs the model to act as a strict schema filter: remove any field not explicitly defined in the provided target schema, log what was removed and why, and return only the cleaned payload. The square-bracket placeholders must be replaced with your actual schema, input data, and operational constraints before use.

textCopy
You are a strict output sanitizer. Your only job is to remove extra hallucinated fields from a model-generated payload.

**Target Schema (canonical field names only):**
[OUTPUT_SCHEMA]

**Payload to clean:**
[INPUT]

**Instructions:**
1. Compare every field in the payload against the Target Schema.
2. If a field exists in the payload but NOT in the Target Schema, remove it entirely.
3. Do not rename, retype, or restructure any field. Only remove extra fields.
4. For every field you remove, record it in a `removals` array with:
   - `field`: the full path of the removed field (use dot notation for nested fields, e.g., `address.line2`)
   - `reason`: a brief explanation (e.g., "not present in target schema")
5. Return a JSON object with exactly two keys:
   - `cleaned_output`: the payload with only schema-approved fields remaining
   - `removals`: the array of removal records
6. If no fields need removal, return the original payload in `cleaned_output` and an empty `removals` array.
7. Do not add commentary, markdown fences, or extra text outside the JSON object.

**Example:**
Target Schema: {"name": "string", "email": "string"}
Input: {"name": "Alice", "email": "alice@example.com", "age": 30, "phone": "555-0100"}
Output:
{
  "cleaned_output": {"name": "Alice", "email": "alice@example.com"},
  "removals": [
    {"field": "age", "reason": "not present in target schema"},
    {"field": "phone", "reason": "not present in target schema"}
  ]
}

**Risk Level:** [RISK_LEVEL]
**Additional Constraints:** [CONSTRAINTS]

To adapt this template, replace [OUTPUT_SCHEMA] with your canonical schema definition—either as a JSON Schema object, a TypeScript interface, or a simple key-type map. Replace [INPUT] with the raw model output you need to clean. Set [RISK_LEVEL] to guide removal aggressiveness: for high-risk domains like healthcare or finance, add a constraint requiring human review of all removals before the cleaned output is accepted. Use [CONSTRAINTS] to inject domain-specific rules, such as "preserve fields prefixed with meta_ even if not in schema" or "escalate removals exceeding 20% of total fields for human review." Always validate the returned cleaned_output against your schema in application code before ingestion—do not rely solely on the model's removal judgment.

This prompt is designed to sit in a post-generation repair loop—after the primary model produces an output but before that output reaches a downstream consumer, database, or user. The harness must receive the original model output, the canonical target schema, and any source grounding evidence as inputs. The prompt returns a cleaned payload and a removal log. Do not call this prompt on outputs that already pass schema validation; it is a repair step, not a primary generation step.

Validation gate: Before calling the prompt, validate the original output against the target schema. If the output already conforms, skip this prompt entirely. After the prompt returns, validate the cleaned output against the same schema. If validation still fails, log the failure and route to a human review queue—do not retry more than twice without changing the prompt or schema. Retry logic: On the first failure, retry once with the same inputs. If the second attempt also fails, escalate. Never loop indefinitely on hallucinated-field removal; the model may be inventing fields because the schema is ambiguous or the source evidence is insufficient.

Logging and observability: Capture the removed_fields array from the prompt output and attach it to your trace. Log the original field count, the removed field count, and the final field count as metrics. This lets you monitor hallucination rates over time and detect schema drift. Human review trigger: If any removed field's name plausibly matches a legitimate field not in the schema (e.g., customer_email removed when email is expected), flag for human review. This prevents false-positive removal of fields that should have been mapped rather than stripped.

Model choice: Use a fast, instruction-following model for this task (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model). The task is structural, not creative. Tool integration: If your system uses a schema registry or API spec as the source of truth, pass the schema definition directly into the [TARGET_SCHEMA] placeholder rather than a human-written summary. This reduces ambiguity. Eval harness: Before deploying, run this prompt against a golden dataset of outputs with known hallucinated fields. Measure precision (did it remove only hallucinated fields?) and recall (did it remove all hallucinated fields?). A recall below 95% means hallucinated fields are leaking downstream; a precision below 95% means legitimate fields are being stripped.

What to avoid: Do not use this prompt as a substitute for proper schema enforcement in your primary generation prompt. If hallucinated fields are frequent, fix the upstream prompt or add structured output constraints first. This prompt is a safety net, not a design pattern. Also avoid running this prompt on streaming outputs mid-stream; assemble the full output first, then repair.