By Greg Nowak. Updated 15 September 2026.
An AI workflow reads an enquiry, prepares a tidy JSON object, and sends it to your CRM. Every required field is present. The customer ID has the right format. Unfortunately, it belongs to another customer.
That is the gap between data that software can read and data your business can trust. JSON gives AI-generated information a predictable structure; it does not establish that the information is correct or that an action is authorised.
For owners, operations leads, and agency teams, the practical goal is straightforward: check the proposed change before it reaches production, and give failures somewhere useful to go.
What structured outputs actually guarantee
A schema describes the expected fields, types, and allowed values. When a provider supports structured outputs, it can constrain generation to that contract. This removes many formatting problems, but provider support has limits.
For example, Claude documents a supported subset of JSON Schema and exceptions for refusals and responses cut short by token limits. A successful HTTP response therefore does not necessarily contain a usable business payload. Check the completion status before parsing or acting on it. See Claude’s structured output documentation.
Keep validation in your application too. Even a perfectly structured payload still needs checks against your customer records, workflow rules, and permissions.
| Checkpoint | What to check | If it fails |
|---|---|---|
| Response | Completed output; no refusal or truncation | Stop and classify the failure |
| Parse and schema | Readable JSON, required fields, types, allowed values | Return a precise error for a bounded repair attempt |
| Business rules | Correct customer, plausible dates, permitted state changes | Retrieve missing evidence or route for review |
| Authority | Allowed action, account scope, required approval | Deny the action and record why |
| Write | Duplicate protection and confirmed downstream result | Reconcile uncertain results before retrying |
Design the fields around the receiving system
Start with the CRM, CMS, or support API. If it accepts only low, normal, and urgent, define those exact values in an enum. For money, specify the currency, unit, precision, and tax treatment.
In JSON Schema, declaring a property does not make it required. Use required explicitly, and use additionalProperties: false where undeclared fields should be rejected. Missing values and null are different; an empty string is another case. Decide whether each means “unknown,” “leave unchanged,” or “clear this field.” The JSON Schema object reference explains these distinctions.
Dates deserve a separate check. By default, JSON Schema’s format keyword is an annotation; enforcement depends on the validator and its configuration. Enable supported format checks and parse dates explicitly in application code. For scheduled actions, define the timezone and acceptable date window. See the format documentation.
Version the schema with the consuming code. Declare the dialect supported by your application validator, and check which constraints the model provider accepts. Keep unsupported rules in application validation.
Keep business decisions tied to real records
Return to the CRM example. Checking that customer_id is a string catches little. Your application should confirm that the record exists, belongs to the current client account, and matches the enquiry. If several customers match, hold the update for review.
Let the model extract information it can reasonably read: the enquiry summary, requested service, or suggested priority. Retrieve authoritative values such as account ownership, permissions, and existing payment status from your systems.
Check combinations of fields as well. A delivery date can be valid yet precede the order date. A ticket status can be allowed yet inappropriate without a resolution. Avoid filling gaps with plausible defaults merely to get a payload through validation.
Give each action a clear permission boundary
The application should decide which tools are available and which arguments it accepts. Scope every lookup and write to the authorised user or client account. This is especially important when an agency’s integration serves several clients through shared infrastructure.
Set approval rules according to consequence. A reversible internal classification may run automatically after checks. Publishing content, changing financial details, or deleting records may need human approval. Define those rules before launch, and bind approval to the exact proposed change.
Separate data repair from write retries
A malformed date may justify one repair attempt with a precise validation error. An ambiguous customer needs more evidence. A denied permission should remain denied. Set a retry limit and avoid sending unnecessary personal data back in error messages.
A timeout after a write is different: the receiving system may already have completed the action. Preserve the validated payload and operation identifier instead of asking the model to generate another version.
Where supported, use an idempotency key: a stable identifier that lets the receiving API recognise a repeated operation. Reuse it for retries of the same request. Check the API’s retention and error behaviour; Stripe, for example, documents parameter matching and key expiry. Without that support, reconcile the downstream result before repeating a write.
Make the handover usable for operations
Before enabling writes, run representative inputs through a preview stage. Test missing fields, unknown IDs, conflicting dates, denied actions, duplicate requests, and timeouts. Include instructions embedded in incoming content that try to redirect the workflow.
Give unresolved cases a named owner and a review queue showing the proposed change, the failed check, and the next action. Log the correlation ID, model and schema versions, validation outcome, retry count, and execution result without collecting unnecessary sensitive data.
Track repeated failures by field and review reason. A workflow that produces valid JSON but needs constant manual correction still needs work.
Need a second pair of eyes before launch?
Greg can help review the handoffs, validation rules, permissions, and recovery paths around your AI integration. Bring one workflow and a representative payload, and discuss what it needs before it starts changing live records.
Related on GrN.dk
- Structured Outputs Make Intake Automation a Schema Design Job
- Your AI workflow has logs. Can they explain one bad decision?
- A Voice Agent Is Only Ready When the Human Handoff Works
Need help with this kind of work?
Discuss your AI workflow with Greg Get in touch with Greg.
