AI can make a form look finished. That does not make its data contract correct. A date picker can display perfectly and still submit a locale-dependent string when the API expects an ISO date, while a checkbox can say yes or no even though the database expects a Boolean.
That gap changes what form review needs to cover. Form design is usually treated as an interface problem, but the form also has to deliver structured data in a compatible shape. AI-generated structured documents and interactive components can satisfy the visible design and still create compatibility issues for the systems that receive their output.
A schema is a boundary, not a decoration
The IETF JSON Schema working group’s active Internet-Draft describes a schema as a set of rules that constrains which JSON values are accepted. That definition puts the important question after the screen is built: does the resulting input belong in the accepted set?
The same schema may help create an interface, but validation still has to decide whether the resulting input belongs in that accepted set. A generated form can borrow the right labels and controls, then send values with the wrong names, types, or properties—an impressive imitation of compatibility that fails at the boundary.
AI does not 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 does not share, which is how a polished component ends up disagreeing with an existing API.
Consider an onboarding form with a field labeled “Customer ID.” A model may name that field customer_id, but the existing API expects account_number. Nothing about the label makes either choice look absurd; the mismatch only becomes visible when the receiving system applies its own contract.
Types and dependencies hide in plain sight
Names are only one failure point. Types create mismatches too: an empty field can arrive as an empty string, null, or no property at all, and those representations are not interchangeable when validation decides which JSON values belong in the accepted set.
OpenAPI 3.2.0 uses Schema Objects to define input and output data types. That gives generated interfaces and APIs a shared place to describe the expected shape, but the description does not remove the need to test the values a form actually sends.
Dependencies are easier to miss because they hide behind user choices. One field can make another required, change which values are valid, or alter the shape of the submitted data without announcing that relationship in the initial layout.
JSON Schema’s conditional validation can express these relationships through dependent requirements and conditional subschemas. That matters because a form is not just a collection of independent controls; its accepted data can depend on combinations of user choices.
Once those dependencies enter the picture, visual review becomes a weak test. A screen can look coherent while its conditional rules, empty values, and field names still disagree with the API or database waiting at the other end.
Validation belongs in the build process
The practical answer is to expose the contract where developers can inspect it. Developer tooling that exposes field names, types, values, and properties makes PDF form field validation part of the build process instead of leaving it as a visual check.
That approach also gives AI-generated components a stricter job. The output must be checked against the names, types, values, properties, dependencies, and accepted JSON values defined by the existing system—not merely judged by whether the interface looks complete.
Schema-driven generation still has a useful role. The same schema may help create an interface, while OpenAPI 3.2.0 uses Schema Objects for input and output data types; the benefit comes when generation and validation use the same contract.
The lesson is not that AI-generated forms are unusable. It is that a plausible interface proves only that the interface is plausible. Compatibility lives in the submitted data, where a locale-dependent date, an empty string, a missing property, or customer_id can meet an API that expects something else.
The central question on August 26, 2026 is simple: does the generated form deliver data in the shape the existing system accepts? If the answer requires inspecting the contract rather than admiring the screen, the screen was never the whole product.
