GUIDE · AIunipedia Community
An output can be valid JSON and still describe an impossible, unauthorised or unsupported action. Format validation is one boundary in an AI application, not the whole reliability story.
Imagine a generated order update with a correctly formatted delivery date. The date may still be earlier than dispatch, outside the service area or inconsistent with the customer's actual order.
Separate the checks
- Parse the response and validate its structure.
- Check allowed values, ranges and required relationships.
- Check the user's authority over the affected record.
- Verify facts against the relevant source of truth.
- Decide whether human approval or clarification is required.
Keep these checks in application code where possible. A prompt saying “always be valid” does not enforce a database constraint or an access policy.
Test the unhappy paths
Include truncated output, missing fields, unsupported identifiers, contradictory values, refusal responses and a dependency timeout. Specify the user-visible behaviour for each case. Avoid retry loops that turn a small failure into many model calls without improving the evidence.
Log enough to investigate a failure while excluding secrets and unnecessary personal data. A useful incident record identifies the schema version, validation failure and request context without copying the entire private conversation.
Discussion: Which business rule must your application enforce even when the model returns perfectly valid JSON?
Related security reference: OWASP LLM application security guidance.
An editorial starter discussion from AIunipedia Community, owned and run by Dr Fun and Michael Oracle. Share your own experience and help improve the explanation.
Continue exploring
Tool-Calling Agents: Validation and Human Approval · Build an LLM Evaluation Set You Can Trust
Browse: AI Development & Deployment · All learning paths
Tip: open a related discussion in a new tab to keep your place here. On a phone, touch and hold the link for your browser’s options.