Skip to main content
A bare "type": "string" accepts anything from a single character to an essay. In production, that string usually ends up in a database column, an API field, or a UI component, all of which have size limits. When the model generates a 2000-character summary for a field that feeds into a 120-character database column, you either truncate (losing information) or reject and retry (wasting time and money). String bounds (minLength, maxLength) and format constraints (pattern, format) solve this at generation time. The model sees the constraints and produces text that already fits, so your application doesn’t need post-processing heuristics.

​
Use case

A support ticket triage payload sent to a ticketing API with strict limits: title must be 10-120 characters, customer_email must be a valid email, and language should be an ISO 639-1 two-letter code.

​
Schema pattern

{
  "type": "object",
  "properties": {
    "title": { "type": "string", "minLength": 10, "maxLength": 120 },
    "summary": { "type": "string", "minLength": 30, "maxLength": 500 },
    "customer_email": { "type": "string", "format": "email" },
    "language": { "type": "string", "pattern": "^[a-z]{2}$" }
  },
  "required": ["title", "summary", "customer_email", "language"],
  "additionalProperties": false
}

​
Example output

{
  "title": "Unable to reset account password from mobile app",
  "summary": "Customer reports reset link opens correctly, but submitting a new password returns a generic error on iOS 18. Reproduced twice with account-specific token.",
  "customer_email": "sam@northwind.io",
  "language": "en"
}

​
Why this works

The minLength/maxLength constraints on title and summary guarantee the output fits the ticketing API’s field limits. Without them, you’d need to truncate or retry, both of which degrade quality or add latency. The pattern constraint on language is stricter than maxLength alone: it enforces exactly two lowercase letters, so you get "en" instead of "English" or "eng". The format: "email" constraint on customer_email guides the model to produce well-formed addresses rather than bare names or partial strings. Together, these constraints replace prompt-level instructions (“keep the title short”, “use ISO language codes”) with enforceable rules that the model cannot violate.