Validate AI-generated JSON at an application boundary

A model can return syntactically valid JSON that asks the application to do something it never supports. Parse the response, validate its structure, then apply the application's business and permission rules before using it.

For a synthetic task suggestion, allow a short title and one action type:

{
  "type": "object",
  "properties": {
    "action": { "enum": ["create_draft"] },
    "title": { "type": "string", "minLength": 1, "maxLength": 120 }
  },
  "required": ["action", "title"],
  "additionalProperties": false
}

This is a JSON Schema fragment for an ordinary application validator. Declare and support a specific schema dialect in the complete schema. Provider-specific structured-output features can accept a subset of a dialect, so inspect that provider's current documentation before sending this schema to its API.

The JSON Schema references explain required and additional object properties, enumerated values and string length.

Generated object passing through schema validation to a typed application record.

Reject a concrete bad suggestion

Use fixtures for a valid draft, an unknown action such as delete_account, a missing title and an unexpected field. Add a response that is ordinary prose instead of JSON. Parsing failure and schema failure should have distinct internal records, even if the user sees one concise recovery message.

Do not repair an unknown action by choosing the "closest" allowed action silently. That can turn an invalid response into an unintended operation. If an application offers a controlled regeneration attempt, bound it and retain the original failure category.

A title containing only spaces can satisfy a minimum string length. Normalize or reject it according to the actual business rule after structural validation. Similarly, a well-formed task title can contain instructions or unsafe content; schema validity alone does not make it appropriate.

Keep validation separate from execution

A valid create_draft suggestion still needs an authorized user and an explicit execution policy. The model should not supply an administrative actor ID or choose the tenant that owns the task. Obtain those from trusted server context.

Validate size before allowing an arbitrarily large response into expensive parsing or downstream processing. Limit stored error details and redact sensitive content from logs. The schema's field limits do not necessarily limit the raw bytes received.

This example defines a boundary and review fixtures. It has not been exercised against a live model or a JSON Schema validator here. Passing these fixtures would establish only that the validator enforces this contract; evaluating whether the suggestion is useful requires a separate set of content judgments.