Min/Max Constraint Prompt for Array and Numeric Field Limits

This prompt is for data engineers and backend developers who need to enforce strict cardinality and numeric range limits in AI-generated JSON. The job-to-be-done is producing structured outputs where arrays respect minItems/maxItems bounds and numeric fields fall within minimum/maximum constraints, without relying on post-generation cleanup scripts. Use this when downstream systems—such as database insert operations, API validation layers, or analytics pipelines—will reject payloads that violate these limits. The ideal user is someone integrating model outputs into an existing data contract where schema validation is non-negotiable.

Do not use this prompt when you only need approximate limits or when the model's native behavior is 'close enough.' It is overkill for free-text generation, creative writing, or conversational outputs. It is also insufficient on its own when constraints are dynamic and must be computed at runtime from a database or configuration service—in those cases, inject the resolved limits into the [CONSTRAINTS] placeholder before sending the prompt. This prompt assumes you already have a target JSON Schema with minItems, maxItems, minimum, and maximum keywords defined. If you need to generate the schema itself, use a schema-generation prompt first, then feed that schema into this constraint-enforcement prompt.

The primary risk is silent constraint violation: the model produces JSON that looks correct but contains an array with 11 items when maxItems is 10, or a score of 1.2 when minimum is 0 and maximum is 1. Always pair this prompt with an automated validation harness that checks every constraint before the output reaches a database or API. For high-stakes pipelines—financial transactions, healthcare records, safety-critical configurations—add a human review step or a hard rejection path that quarantines invalid outputs rather than attempting automatic repair. Start by copying the prompt template, replacing the placeholders with your schema and input data, and running it against a golden test set of boundary-condition examples before deploying to production.

This prompt template is designed to enforce structural and numeric boundaries within generated JSON outputs. It instructs the model to treat minItems, maxItems, minimum, and maximum constraints as hard rules, not suggestions. The template is schema-agnostic, meaning you can swap in any JSON Schema definition that includes these constraint keywords. Use it when downstream systems will reject payloads that violate array size limits or numeric bounds, such as a payment API that requires exactly one funding source or a sensor ingestion pipeline that discards values outside a calibrated range.

textCopy
You are a strict JSON generator. Your output must be a single valid JSON object that conforms to the provided JSON Schema.

# SCHEMA
[JSON_SCHEMA]

# INPUT DATA
[INPUT_TEXT]

# ABSOLUTE CONSTRAINTS
- Array fields: Respect all `minItems` and `maxItems` constraints exactly. If the input data provides fewer items than `minItems`, you must not fabricate data to fill the array; instead, set the field to `null` or omit it if allowed by the schema. If the input provides more items than `maxItems`, select only the first `maxItems` items based on the order they appear in the input.
- Numeric fields: Respect all `minimum` and `maximum` constraints. If an extracted value falls outside the allowed range, clamp it to the nearest valid boundary (minimum or maximum) and set the `[OUT_OF_RANGE_FLAG_FIELD]` to `true` for that field. If the schema defines `exclusiveMinimum` or `exclusiveMaximum`, treat the boundary value itself as invalid and clamp to the next valid increment.
- Do not add commentary, markdown fences, or extra text. Output only the JSON object.

# OUTPUT

To adapt this template, replace [JSON_SCHEMA] with your target schema containing minItems/maxItems on arrays and minimum/maximum on numbers. Replace [INPUT_TEXT] with the unstructured source data. The [OUT_OF_RANGE_FLAG_FIELD] placeholder should be replaced with a field name from your schema designed to capture constraint violations, such as value_clamped. If your application cannot tolerate clamping, modify the numeric constraint paragraph to instruct the model to omit the field entirely and log a violation in a separate constraint_violations array. Always pair this prompt with a post-generation validation harness that checks the actual output against the schema using a standard JSON Schema validator before the data enters any critical path.

The Min/Max Constraint Prompt is designed to sit inside a structured generation pipeline where array cardinality and numeric range compliance are non-negotiable. You should not treat this prompt as a standalone magic function. Instead, wrap it in an application harness that validates the output against the same JSON Schema you provided in [OUTPUT_SCHEMA] before the response ever touches a database, API endpoint, or downstream consumer. The harness is responsible for enforcing the contract the prompt was asked to follow.

Start by constructing the prompt request with the target schema, the source [INPUT] data, and any [CONSTRAINTS] that describe business rules beyond what the schema can express (e.g., 'maxItems must not exceed the user's subscription tier limit'). Send the assembled prompt to a model that supports structured output or JSON mode. When the response arrives, immediately validate it with a JSON Schema validator such as ajv (JavaScript), jsonschema (Python), or equivalent. Check specifically for minItems, maxItems, minimum, maximum, exclusiveMinimum, and exclusiveMaximum violations. If validation fails, capture the specific constraint violation errors and feed them back into a retry prompt that includes the original request, the invalid output, and the exact validation error messages. Limit retries to a maximum of 2-3 attempts to avoid infinite loops. Log every attempt—including the raw prompt, model response, validation result, and retry count—for observability and debugging.

For high-stakes pipelines where a constraint violation could cause financial, compliance, or safety issues, insert a human review step after the final retry. If the output still fails validation after all retries, route the record to a review queue with the full attempt history rather than silently dropping it or forcing a best-guess repair. When choosing a model, prefer those with native structured output support (e.g., GPT-4o with response_format, Claude with tool use for JSON) to reduce the base rate of schema violations. Avoid using this prompt with models that lack reliable JSON generation unless you add a repair layer that can fix common structural errors before schema validation. The harness should also monitor for boundary condition failures—arrays that hit exactly minItems or maxItems, numbers at exact minimum or maximum—since these are the most common points where model outputs drift from constraints under load or with ambiguous inputs.