The Form Looks Right. The Data Contract Is Wrong

PUBLISHER ARTICLE PREVIEW

From the original article

The question isn’t whether an AI-built form can look ready for production. It’s whether the system receiving its data will agree.

A date picker can display perfectly and still submit a locale-dependent string when the API expects an ISO date. A checkbox can say yes or no while the database expects a Boolean. The demo passes, the screenshot looks clean, and the failure waits downstream.

Form design is usually reviewed as an interface problem. Can people understand the labels? Does the tab order make sense? Does the page behave on a phone? Those questions matter, but they don’t describe the whole job.

A form also promises to deliver structured data in a shape another system can interpret. That promise covers field names, data types, required values, allowed options, defaults, identifiers and destination mappings. Change one of them without changing the receiving system, and a polished interface can become an unreliable integration.

That boundary gets harder to see as generative AI document automation moves beyond drafting text and starts producing structured documents and interactive components. Generation is fast because a model can infer a plausible layout from a short description. Plausible, however, isn’t the same as compatible.

The IETF JSON Schema working group’s active Internet-Draft, last updated on August 26, 2026, describes a schema as a set of rules that constrains which JSON values are accepted. It also discusses generative uses such as UI renderers. That pairing gets to the heart of the issue: the same schema may help create an interface, but validation still has to decide whether the resulting input belongs in the accepted set.

AI doesn’t need to produce obviously broken code to create a bad contract. It only needs to make a reasonable assumption that the rest of the system doesn’t share.

Imagine an onboarding form with a field labeled “Customer ID.” The model names the field customer_id, which looks sensible. The existing API still expects account_number. Every test user can fill in the box, but unless the integration rejects or translates the unexpected property, the identifier may never reach the correct record.

Types create the same kind of mismatch. An empty field might arrive as an empty string, null, or no property at all. A number may arrive as text. A dropdown might display friendly