String-to-Number Coercion Prompt Template

This prompt is designed for data engineers and backend developers who receive numeric values represented as strings from large language model (LLM) outputs. The core job-to-be-done is converting these string representations into correct, typed numeric values (integers or floats) while preserving precision. This is a critical step when a model's output is semantically correct but typed incorrectly, preventing direct ingestion into databases, analytics pipelines, or strictly-typed API contracts. The ideal user is integrating an LLM into a data pipeline and needs a reliable, automated repair step before downstream processing.

Use this prompt when your application receives strings like "$1,234.56", "1.5e3", "25%", or "1,234,567.89" and you require a native numeric type. It is particularly valuable when dealing with locale-specific formats, currency symbols, thousand separators, and scientific notation. The prompt template is designed to be wired into a post-generation validation and repair loop. You should configure it with explicit constraints for acceptable ranges, precision requirements, and a clear policy for handling unparseable inputs. Do not use this prompt for simple integer parsing that can be handled by standard library functions like parseInt or parseFloat in your application code; its strength lies in handling the ambiguous and formatted cases that cause those functions to fail or return NaN.

Before implementing this prompt, ensure you have a clear definition of the target numeric type and precision. The prompt is not a substitute for strict schema validation; it is a repair step. You must still validate the final output against your schema. Avoid using this prompt for direct user-facing interactions without a human-in-the-loop review for high-risk financial or scientific data. The next step after reading this section is to review the prompt template and adapt its placeholders to your specific input format and output requirements.

This prompt template converts string representations of numbers into properly typed numeric values. It handles currency symbols, thousand separators, locale-specific decimal formats, scientific notation, and edge cases like negative values in parentheses. The template is designed to be dropped into a validation pipeline where model outputs arrive as strings but downstream systems require strict numeric types.

textCopy
You are a numeric coercion engine. Your task is to convert string representations of numbers into correct numeric types while preserving precision.

INPUT:
[INPUT]

EXPECTED OUTPUT TYPE: [OUTPUT_TYPE]

CONSTRAINTS:
[CONSTRAINTS]

RULES:
1. Strip currency symbols ($, €, £, ¥, etc.) and return the raw numeric value.
2. Handle thousand separators (commas, periods, spaces) according to the locale specified in [LOCALE].
3. Normalize decimal separators to a period (.) for the output.
4. Convert negative numbers expressed with parentheses, trailing minus signs, or CR/DR notation to standard negative values.
5. Parse scientific notation (e.g., "1.5e3") into the correct numeric value.
6. If the input contains non-numeric text that cannot be interpreted as a number, return null and flag it.
7. Preserve the precision specified in [PRECISION]. Do not introduce floating-point drift.
8. Validate that the coerced value falls within [MIN_VALUE] and [MAX_VALUE]. If outside bounds, flag it.

OUTPUT SCHEMA:
{
  "original": "string",
  "coerced_value": number | null,
  "type": "[OUTPUT_TYPE]",
  "precision_applied": number,
  "flags": ["string"],
  "confidence": number
}

FLAGS TO USE:
- "overflow": value exceeds MAX_VALUE
- "underflow": value below MIN_VALUE
- "precision_loss": original precision could not be preserved
- "unparseable": input could not be interpreted as a number
- "locale_ambiguity": separator format was ambiguous for the given locale
- "scientific_notation": input was in scientific notation
- "currency_stripped": currency symbol was removed
- "parentheses_negative": negative value was expressed with parentheses

Return ONLY valid JSON. No markdown fences, no commentary.

To adapt this template, replace the square-bracket placeholders with your specific requirements. Set [OUTPUT_TYPE] to integer, float, or decimal depending on your downstream schema. Define [PRECISION] as the number of decimal places to preserve. Set [MIN_VALUE] and [MAX_VALUE] to catch out-of-range values before they hit your database. The [LOCALE] parameter is critical for disambiguating thousand and decimal separators—specify en-US, de-DE, fr-FR, or similar to prevent misinterpretation of values like "1.234,56".

For production use, always validate the output JSON against the schema before ingestion. If the confidence score drops below your threshold or flags contains unparseable, route the record to a manual review queue rather than silently inserting a null. When processing financial data, set [PRECISION] explicitly and test with edge cases like "$0.00", "(1,234.56)", and "1.5e-3" to confirm the coercion behaves as expected.

The string-to-number coercion prompt is designed to sit inside a post-generation repair loop, not as a standalone service. After your primary model produces an output containing numeric fields serialized as strings, route those fields through this prompt before they reach your database, API response, or analytics pipeline. The prompt expects a single string value or a small batch of string values alongside a [TARGET_TYPE] and [CONSTRAINTS] block. Do not send entire model responses through this prompt—extract only the numeric fields that failed downstream type validation to keep latency and token costs low.

Wrap the prompt call in a thin application function that performs pre-flight checks before invoking the model. Validate that the input is actually a string (not already a number, null, or undefined) and that it contains at least one digit character. If the string is empty or purely non-numeric, skip the model call and apply your default policy directly (e.g., null, 0, or raise an exception). After the model returns, parse the output against the expected [TARGET_TYPE] using a strict type check in your application code—typeof result === 'number' in JavaScript, isinstance(result, (int, float)) in Python, or equivalent. If the parsed value violates [CONSTRAINTS] such as min/max bounds or precision limits, log the violation and either retry with a more explicit constraint message or escalate for human review. For high-throughput pipelines, batch up to 20 string values per prompt call and request a JSON array output to amortize model latency.

Choose a fast, inexpensive model for this repair task. String-to-number coercion is a deterministic parsing problem that does not require reasoning or creativity, so a smaller model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned open-weight model) will handle it reliably at lower cost and latency. Set temperature=0 to eliminate variance. If your application processes financial amounts, scientific measurements, or other precision-sensitive values, add a post-model validation step that compares the coerced number against the original string using a round-trip check: format the number back to a string with the expected precision and verify it matches the original after normalizing both. Mismatches indicate precision loss and should trigger an alert. Log every coercion event with the original string, the coerced value, the model used, and whether validation passed—this audit trail is essential for debugging downstream data quality issues and demonstrating compliance in regulated environments.