Type Coercion and Normalization Check Prompt

This prompt is built for integration engineers and platform developers who are responsible for ingesting LLM outputs into strictly typed downstream systems—databases, APIs, data warehouses, or serialization layers. The job-to-be-done is not to judge the semantic quality of the output, but to verify that every field can survive a type coercion and normalization pass without silent data loss, precision truncation, or format ambiguity. Use this prompt when you have a target schema with explicit type expectations (e.g., decimal(10,2), ISO 8601 datetime, int32) and you need a machine-readable report that flags which values will break, which will silently corrupt, and which are safe to pass through.

The ideal user provides three things: the raw LLM output to be checked, the target type map or schema definition, and the coercion rules that the ingestion pipeline will apply (e.g., 'string to float uses parseFloat, nulls become empty strings, dates must match YYYY-MM-DD'). The prompt works best when the coercion rules are explicit and deterministic—if your pipeline has fuzzy or locale-dependent parsing, you should encode those rules in the [COERCION_RULES] placeholder rather than relying on the model to guess them. Do not use this prompt for semantic validation, business rule checking, or content policy enforcement; those are separate concerns that belong in other assertion prompts like the Custom Business Rule Validator or Content Policy Rule Check.

Avoid this prompt when the target system is schema-flexible (e.g., a document store that accepts arbitrary JSON), when type coercion is handled entirely by application code with well-tested parsing libraries, or when the output volume is so high that per-record LLM validation becomes cost-prohibitive. In those cases, prefer deterministic validation in code. Also avoid this prompt for outputs that are already validated by a strict JSON Schema compliance check—type coercion and normalization is a downstream concern that assumes the output is structurally valid but may contain type-ambiguous values. If you need structural validation first, use the JSON Schema Compliance Check Prompt as a gate before running this coercion check.

This prompt template is designed to be dropped into a validation step within your CI/CD pipeline or post-generation harness. It takes a structured output and a target schema, then checks each field for type coercion safety, normalization failures, and precision issues. The prompt is model-agnostic and expects square-bracket placeholders to be replaced by your application before inference. Use it when you need a machine-readable verdict on whether an LLM's output will break downstream type systems, ETL jobs, or API contracts.

textCopy
You are a type coercion and normalization validator. Your task is to check whether each field in the provided [OUTPUT_OBJECT] can be safely coerced to the target types defined in [TARGET_SCHEMA] without data loss, ambiguity, or normalization failure.

[OUTPUT_OBJECT]:
```json
[OUTPUT_OBJECT]

[TARGET_SCHEMA]:

jsonCopy
[TARGET_SCHEMA]

[CONSTRAINTS]:

• Flag any field where coercion would cause truncation, rounding, or loss of precision.
• Flag ambiguous date/time/number formats that cannot be deterministically parsed.
• Flag null values in required fields.
• Flag enum values not present in the allowed set.
• Flag string values that exceed maximum length constraints.
• Do not flag fields that are already in the correct type and format.

Return a JSON object with this structure: { "overall_verdict": "PASS" | "FAIL", "field_results": [ { "field_path": "string", "source_value": "any", "source_type": "string", "target_type": "string", "coercion_possible": true | false, "coerced_value": "any or null", "data_loss": true | false, "loss_description": "string or null", "normalization_issue": true | false, "issue_description": "string or null", "verdict": "PASS" | "FAIL" } ] }

To adapt this prompt, replace [OUTPUT_OBJECT] with the serialized JSON output from your LLM or extraction step. Replace [TARGET_SCHEMA] with a JSON Schema object that includes type, format, enum, maxLength, and required constraints. The [CONSTRAINTS] section is a starting point—extend it with domain-specific rules such as numeric range checks, regex patterns, or cross-field dependencies. For high-risk pipelines, always pair this prompt with a deterministic post-check in application code that independently verifies the coercion results before accepting the verdict.

This prompt is designed to be a deterministic gate in an automated data ingestion or ETL pipeline. It should be called after an LLM generates a structured output but before that output is written to a target database, data warehouse, or API contract. The primary integration point is a post-generation validation step where the raw LLM output and the target schema are both available. The prompt expects a JSON object containing the [OUTPUT] to validate and a [TARGET_SCHEMA] defining the expected types, formats, and constraints for each field. The harness should construct this input programmatically from the upstream LLM's response and the downstream system's schema registry or type definitions.

The implementation must treat this prompt's output as a machine-readable verdict. Parse the response into a structured object with a top-level pass boolean and a checks array. Each check should contain the field name, input_value, target_type, coercion_possible boolean, and any warnings about precision loss or format ambiguity. The harness should log the full prompt response for every validation run, regardless of pass/fail status, to create an audit trail for debugging normalization failures. For high-throughput pipelines, consider batching multiple fields into a single prompt call to reduce latency, but ensure the prompt's context window can accommodate the batch without truncation. If a field fails with coercion_possible: false, the harness should route the record to a dead-letter queue for manual review rather than silently dropping it or coercing with data loss.

For CI/CD integration, wrap this prompt in a test harness that runs against a golden dataset of known outputs and their expected normalization results. The test should assert that the prompt correctly identifies coercible types (e.g., string "123" to integer) and correctly flags lossy coercions (e.g., float 3.14159 to integer). Set explicit thresholds: the prompt must achieve 100% recall on blocking normalization failures (no false negatives for data loss) and at least 95% precision on flagging true issues (acceptable false positives are routed to human review, not blocked). If the prompt is used as a release gate, the CI/CD pipeline should block deployment if the recall threshold is breached. For model selection, prefer models with strong JSON output discipline and low hallucination rates on structured comparison tasks; GPT-4o and Claude 3.5 Sonnet are suitable defaults, but always validate the output schema before trusting the verdict. Implement a retry with exponential backoff if the prompt response fails to parse as valid JSON, and escalate to a human operator after three failed retries.