Null Handling Demonstration Prompt for Missing Data

This prompt is for integration engineers building extraction pipelines that must survive incomplete, messy, or partially redacted source text. Its primary job is to teach the model a deterministic contract for representing missing data, distinguishing between an empty string, a genuinely missing field, and a field that should be explicitly null. Use this when downstream consumers—such as strict-schema databases, typed APIs, or analytics systems—break on empty string substitution or silent field omission. The target reader is an engineer who needs predictable null behavior in a production data pipeline, not a content author or someone doing creative text generation.

The prompt works by providing carefully constructed few-shot examples that demonstrate the correct output for three distinct cases: a field with an empty value (""), a field that is entirely absent from the source (null), and a field that is present but contains no meaningful data (also null, depending on the contract). Counterexamples are included to show incorrect behaviors like substituting an empty string for a missing field or silently dropping a field that should be present. This is critical when the output feeds directly into systems that validate JSON Schema with "type": ["string", "null"] or database columns with NOT NULL constraints. The prompt is designed to be prepended to your existing extraction instructions, adding a null-handling layer without rewriting your core schema.

Do not use this prompt for summarization, creative text generation, or workflows where null semantics are not contract-critical. If your downstream consumer treats a missing key and a null value identically, the added token cost and complexity are unnecessary. Similarly, avoid this prompt when the model's base behavior already aligns with your null contract—over-specifying can sometimes degrade output quality. Before deploying, run the prompt against a golden test set that includes empty strings, missing fields, and explicit null values, and validate the output with a schema validator that enforces your exact nullability rules. If the extraction involves regulated data, add a human review step for any record where the model's null decision conflicts with a confidence threshold.

This template is designed to be pasted directly into your system prompt or as a user message in your extraction pipeline. Its core teaching mechanism is the set of few-shot examples, which demonstrate the exact behavior you expect for null, empty, and missing fields. The examples are not optional; they are the primary instruction set. Do not remove them without replacing them with equivalent demonstrations that cover the same edge cases. The placeholders in square brackets, such as [TARGET_SCHEMA] and [INPUT_TEXT], must be replaced with your specific schema and data before use.

textCopy
You are a precise data extraction engine. Your only job is to extract information from the provided text and populate a JSON object that strictly conforms to the provided schema.

# Output Schema
You must output a single JSON object with the following fields. Do not add any fields that are not listed here.
[TARGET_SCHEMA]

# Critical Rules for Missing Data
1.  **Explicit Null:** If a field is mentioned in the text but its value is explicitly stated as unknown, not applicable, or null, you must output the JSON value `null`.
2.  **Empty String:** If a field is mentioned but its value is an empty string (e.g., "the comment field was left blank"), you must output the JSON value `""`.
3.  **Missing Field:** If a field in the schema is not mentioned at all in the input text, you must omit the key entirely from the output JSON object. Do not output the key with a null value.

# Examples
Follow the pattern demonstrated in these examples exactly.

## Example 1: Standard Extraction
Input:
"Customer: Acme Corp, Contact: John Doe, Phone: 555-0100, Email: [email protected]"
Output:
{
  "customer_name": "Acme Corp",
  "contact_name": "John Doe",
  "phone_number": "555-0100",
  "email_address": "[email protected]",
  "secondary_phone": null,
  "notes": ""
}

## Example 2: Explicit Null and Empty String
Input:
"Customer: Globex, Contact: Jane Smith. The secondary phone is not available. Notes field was left blank."
Output:
{
  "customer_name": "Globex",
  "contact_name": "Jane Smith",
  "phone_number": null,
  "email_address": null,
  "secondary_phone": null,
  "notes": ""
}

## Example 3: Missing Field (Key Omission)
Input:
"Customer: Initech, Contact: Bill Lumbergh"
Output:
{
  "customer_name": "Initech",
  "contact_name": "Bill Lumbergh"
}

## Example 4: Counterexample - Incorrect Null Substitution
Input:
"Customer: Initech, Contact: Bill Lumbergh"
Incorrect Output (Do not do this):
{
  "customer_name": "Initech",
  "contact_name": "Bill Lumbergh",
  "phone_number": "",
  "email_address": "",
  "secondary_phone": "",
  "notes": ""
}
This is incorrect because missing fields were filled with empty strings instead of being omitted.

# Input Text to Process
[INPUT_TEXT]

# Your JSON Output:

To adapt this template, start by replacing [TARGET_SCHEMA] with your own JSON schema. Ensure your schema includes fields that can test all three null-handling states. Next, replace the examples with your own domain-specific examples that mirror the exact patterns shown: one for standard extraction, one demonstrating explicit null and empty strings, one demonstrating key omission for missing data, and one counterexample showing an incorrect pattern. Finally, replace [INPUT_TEXT] with the actual text you want to process. For high-risk domains like healthcare or finance, add a [RISK_LEVEL] placeholder and a final instruction like: "If the input is ambiguous or could lead to an incorrect medical/financial assertion, output a JSON object with a single key "error" and a descriptive message, and halt further processing."

The null-handling demonstration prompt is designed to sit inside a larger extraction pipeline, typically after an initial extraction attempt and before downstream ingestion. Its job is narrow: take a raw model output that may contain ambiguous empty values and normalize it into a schema where null, empty string "", and missing keys have explicit, consistent meanings. Wire this prompt as a post-processing step, not as the primary extraction prompt. The primary extraction should attempt to populate all fields; this prompt handles the cleanup and disambiguation of missing or empty data.

Pipeline placement and invocation: Call this prompt after your primary extraction step returns a JSON object. Pass the raw extraction output as [EXTRACTION_OUTPUT] and your target schema with nullability annotations as [OUTPUT_SCHEMA]. Include [FIELD_DEFINITIONS] that specify, per field, whether the field is required, nullable, or has a default value. The model should receive few-shot examples that demonstrate the exact null representation your downstream systems expect—typically JSON null for unknown values, empty string "" only when the source explicitly contains an empty value, and omitted keys only when the schema marks them as optional and truly absent. Validation layer: After the prompt returns, run a schema validator that checks: (1) all required fields are present, (2) no field contains a placeholder like "N/A" or "missing" unless explicitly allowed, (3) null values appear only in nullable fields, and (4) empty strings appear only where semantically correct. If validation fails, retry once with the validation error message appended to the prompt as [PREVIOUS_ERROR]. If the second attempt fails, route to a human review queue with the original extraction, both attempts, and the validation errors logged.

Model choice and configuration: Use a model with strong instruction-following and JSON output capabilities. Set temperature=0 to minimize variance in null representation. Enable structured output mode if your provider supports it, binding the response to your target schema directly. Logging and observability: Log every invocation with: the input extraction, the normalized output, validation pass/fail status, retry count, and any human review escalation. Track metrics on null-field frequency, empty-string vs null confusion rate, and retry rate. These metrics will surface when your upstream extraction model changes behavior or when input data distributions shift. What to avoid: Do not use this prompt as a general-purpose data cleaner—it is specifically for null and empty-value disambiguation. Do not skip the validation layer; silent null-meaning errors corrupt downstream analytics and are hard to detect without explicit checks. Do not retry more than twice; after two failures, the ambiguity is likely in the source data itself and requires human judgment.