Default Value Assignment Prompt Template for Missing Fields

This prompt is designed for ETL engineers, data pipeline builders, and API developers who must transform sparse, incomplete records into complete, schema-conformant payloads. The core job-to-be-done is field-level default value assignment: when an input record is missing a field defined in your target schema, the model should populate that field with a pre-defined default value rather than omitting it, hallucinating a value, or returning an error. This is critical for downstream systems that require every record to have the same shape, such as relational databases with NOT NULL constraints, analytics platforms expecting complete columns, or strict API contracts that reject partial objects.

Use this prompt when you control the target schema and can provide an explicit default-value map. The ideal user has a JSON Schema, a database table definition, or a typed interface contract and needs a reliable, automated way to hydrate missing fields before ingestion. The prompt works best when the defaults are static, deterministic values (e.g., empty strings, zero, false, empty arrays, or known sentinel values like 'UNKNOWN'). It is not suitable for dynamic defaults that require computation, lookups from external systems, or business logic that depends on the values of other fields. For those cases, handle the logic in application code before or after the model call.

Avoid this prompt when the presence or absence of a field carries semantic meaning that must be preserved. If null is a valid and distinct state from a default value, use the Nullable Field Control Prompt Template instead. If you need to prevent the model from inventing values for missing fields without providing defaults, use the Required vs Optional Field Declaration Prompt Template. This prompt assumes you want every field in the output, every time, with explicit fallback values. Before implementing, ensure your default-value map is complete—any field in the target schema that lacks a default will be a source of production drift.

This prompt template is designed for ETL engineers and API developers who need to produce complete, schema-conformant records from sparse or partial inputs. The core instruction tells the model to treat a provided schema as the source of truth for default values: if a field is absent or null in the input, the model must populate it from the schema's default definition. If a field is present with a non-null value, that value must be preserved exactly as provided. The template uses square-bracket placeholders so you can swap in your own schema, input data, output format, and constraints without rewriting the core logic.

textCopy
You are a data normalization engine. Your task is to produce a complete, valid record by applying default values from a schema to any missing or null fields in the input data.

## SCHEMA
[SCHEMA_DEFINITION]

## INPUT DATA
[INPUT_DATA]

## RULES
1. For every field defined in the SCHEMA, check whether the field is present and non-null in the INPUT DATA.
2. If a field is missing from the INPUT DATA or its value is null, assign the default value specified in the SCHEMA for that field.
3. If a field is present in the INPUT DATA with a non-null value, preserve that value exactly. Do not overwrite, coerce, or reinterpret it.
4. If the SCHEMA does not define a default for a missing field, follow the [MISSING_FIELD_POLICY: omit | null | error].
5. Do not add any fields that are not defined in the SCHEMA.
6. Do not include commentary, explanations, or markdown formatting outside the output structure.

## OUTPUT FORMAT
[OUTPUT_SCHEMA]

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

Produce the output now.

To adapt this template, start by replacing [SCHEMA_DEFINITION] with your actual field definitions, including each field's name, type, and default value. Use a structured format like JSON Schema with default keywords, or a simple table if your model handles that well. Replace [INPUT_DATA] with the sparse record you need to complete. The [MISSING_FIELD_POLICY] placeholder forces you to decide what happens when a field has no default: omit it from the output, set it to null, or raise an error. Choose [OUTPUT_SCHEMA] to match your downstream consumer—typically JSON with explicit field ordering. Add [CONSTRAINTS] for any type-enforcement rules, such as "all numeric fields must be integers, not strings." Include 2–3 [EXAMPLES] showing sparse inputs and the expected completed outputs so the model learns the pattern. Before deploying, run eval checks that verify: (a) provided values are never overwritten, (b) missing fields receive exactly the schema-defined default, (c) no extra fields appear, and (d) the missing-field policy is followed when no default exists.

The Default Value Assignment prompt template is designed to sit inside a data ingestion or transformation pipeline where sparse records arrive and must be completed before downstream consumers reject them. The typical integration point is a pre-ingestion normalization step: an API endpoint receives a partial JSON payload, a message queue delivers an incomplete event, or a batch job reads CSV rows with missing columns. The application layer should first parse the incoming record, extract the fields that are present, and then construct the prompt with the [INPUT_RECORD] containing only the provided fields, the [FIELD_SCHEMA] defining every expected field with its type and default value, and the [OUTPUT_SCHEMA] describing the exact shape the completed record must match. The model call should be treated as a deterministic completion step, not a creative generation step, so temperature should be set to 0 or near-zero (0.0–0.1) and top_p should be tightly constrained to avoid variation in default value selection.

Validation must happen in two layers. First, a pre-generation check should verify that the [FIELD_SCHEMA] is well-formed: every field has a declared type, a default value of the correct type, and no circular references in nested objects. Second, a post-generation validator should parse the model's output and confirm that every field in the schema is present, that no provided values were overwritten with defaults (compare against the original [INPUT_RECORD]), and that all default-assigned fields match their declared types. For high-stakes pipelines, implement a diff reporter that logs exactly which fields received defaults and which were preserved from input. This diff becomes part of the audit trail. If validation fails, the harness should retry once with the same prompt plus the validation error message appended as a [PREVIOUS_ERROR] context field. If the second attempt also fails, escalate to a human review queue rather than silently dropping the record or passing malformed data downstream.

Model choice matters for this prompt. The task requires strict instruction following and schema adherence, not creative reasoning. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro all perform well on default-value assignment when temperature is low. For cost-sensitive bulk pipelines, consider smaller models like GPT-4o-mini or Claude 3 Haiku, but increase eval rigor: run a batch pre-flight test with 50–100 known sparse records and verify that default assignment accuracy exceeds your pipeline's tolerance threshold (typically >99.5% for financial or healthcare data). Do not use this prompt with models that have known JSON formatting instability without adding a repair step. The harness should also enforce a timeout and max token limit based on your record size: for records under 50 fields, 4096 output tokens is usually sufficient. Log every model call with the input record hash, the output record hash, the diff of default-assigned fields, the model version, and the latency. This log becomes essential for debugging field-level drift when you upgrade model versions or modify the field schema.

When integrating with streaming or high-throughput systems, batch records where possible. Send up to 10 sparse records in a single prompt as a JSON array, with the same [FIELD_SCHEMA] applied to each element. This reduces per-record latency and token overhead. The output should be validated element-by-element, and partial failures should not block successful records. If your pipeline cannot tolerate any default-assignment errors, implement a circuit breaker: if the failure rate exceeds 1% in a rolling window of 1000 records, pause the pipeline and alert the data engineering team. For regulated domains, every default-assigned record should carry a metadata field (added by the harness, not the model) marking it as default_augmented: true with a timestamp and the schema version used. This ensures downstream consumers and auditors can distinguish between original and completed data without relying on the model to self-report accurately.