Het formulier ziet er goed uit. Het gegevenscontract is onjuist

De vraag is niet of een door AI gebouwd formulier er klaar voor productie uitziet. Het is of het systeem dat de gegevens ontvangt, akkoord gaat.

Een datumkiezer kan er perfect uitzien en toch een op de locale gebaseerde tekenreeks indienen terwijl de API een ISO‑datum verwacht. Een selectievakje kan ja of nee aangeven terwijl de database een Booleaanse waarde verwacht. De demo slaagt, de screenshot ziet er netjes uit, en de fout wacht stroomafwaarts.

Wat belooft het formulier eigenlijk?

Formulierontwerp wordt meestal beoordeeld als een interface‑probleem. Kunnen mensen de labels begrijpen? Heeft de tabvolgorde zin? Gedraagt de pagina zich goed op een telefoon? Die vragen zijn belangrijk, maar ze beschrijven niet het volledige werk.

Een formulier belooft ook gestructureerde gegevens te leveren in een vorm die een ander systeem kan interpreteren. Die belofte omvat veldnamen, gegevenstypen, verplichte waarden, toegestane opties, standaardwaarden, identifiers en bestemmingskoppelingen. Verander één daarvan zonder het ontvangende systeem aan te passen, en een gepolijste interface kan een onbetrouwbare integratie worden.

Die grens wordt moeilijker te zien naarmate generatieve AI-documentautomatisering verder gaat dan het opstellen van tekst en gestructureerde documenten en interactieve componenten begint te produceren. Generatie is snel omdat een model een plausibele lay-out kan afleiden uit een korte beschrijving. Plausibel is echter niet hetzelfde als compatibel.

Het actieve Internet-Draft van de IETF JSON Schema‑werkgroep, voor het laatst bijgewerkt op 26 augustus 2026, beschrijft een schema als een reeks regels die bepalen welke JSON‑waarden worden geaccepteerd. Het bespreekt ook generatieve toepassingen zoals UI‑renderers. Die combinatie raakt de kern van het probleem: hetzelfde schema kan helpen een interface te creëren, maar validatie moet nog steeds bepalen of de resulterende invoer tot de geaccepteerde set behoort.

Waarom wijkt het contract af?

AI hoeft geen duidelijk defecte code te produceren om een slecht contract te creëren. Het hoeft alleen een redelijke veronderstelling te maken die de rest van het systeem niet deelt.

Stel je een onboarding‑formulier voor met een veld gelabeld “Customer ID”. Het model noemt het veld customer_id, wat logisch lijkt. De bestaande API verwacht nog steeds account_number. Elke testgebruiker kan het vakje invullen, maar tenzij de integratie de onverwachte eigenschap afwijst of vertaalt, bereikt de identifier mogelijk nooit het juiste record.

Typen veroorzaken dezelfde soort mismatch. Een leeg veld kan aankomen als een lege tekenreeks, null, of helemaal geen eigenschap. Een getal kan als tekst aankomen. Een keuzelijst kan vriendelijke labels weergeven terwijl het ontvangende systeem stabiele codes verwacht. OpenAPI 3.2.0 gebruikt Schema‑objecten om invoer‑ en uitvoergegevens te definiëren, waardoor teams een machine‑leesbare beschrijving krijgen om te vergelijken met het formulier in plaats van te vertrouwen op wat het scherm lijkt te verzamelen.

Afhankelijkheden zijn makkelijker te overzien omdat ze zich verbergen achter gebruikerskeuzes. Het selecteren van een land kan een veld voor staat, provincie of regio verplicht maken. Het kiezen van “company” in plaats van “individual” kan een registratienummer vereisen. De conditionele validatie van JSON Schema kan deze relaties uitdrukken via afhankelijke vereisten en conditionele subschema’s, maar een gegenereerd formulier moet nog steeds dezelfde regels implementeren.

Ontwikkelaarstools die veldnamen, typen, waarden en eigenschappen blootleggen, maken PDF-formulierveldvalidatie onderdeel van het bouwproces in plaats van een visuele controle aan het einde. Dat vervangt geen schema‑validator of een API‑contracttest. Het geeft ontwikkelaars controle over de formulier‑kant objecten die die tests moeten inspecteren.

Er is een andere bron van afwijking: het formulier en het contract kunnen aanvankelijk op één lijn liggen, maar vervolgens op verschillende tijdschema’s veranderen. Een prompt wordt herzien. Een veldlabel wordt hernoemd. De API verwijdert een optie of introduceert een nieuwe verplichte eigenschap. Niemand ziet een kapotte lay-out, dus de wijziging lijkt onschadelijk.

Dat is het niet.

Hoe test je meer dan alleen het gelukkige pad?

Een succesvolle inzending bewijst dat één combinatie van waarden eenmaal werkte. Productieformulieren hebben een strengere beoordeling nodig.

Begin met de payload, niet met de screenshot. Dien een voorbeeld in dat bekend goed is en vergelijk de feitelijke geserialiseerde output met het contract. Controleer eigenschapsnamen, typen, nesting en toegestane waarden. Stuur die payload vervolgens door de echte integratie en bevestig dat dezelfde waarden de round‑trip naar het CRM, ERP of de database en terug naar elk beoordelingsscherm overleven.

De volgende tests moeten zo ontworpen worden dat ze falen. Probeer een ontbrekende verplichte waarde, een lege tekenreeks waar null wordt verwacht, een getal buiten zijn grenzen, een onverwachte keuzelijstoptie en een eigenschap die het contract niet herkent. Een nuttige validatielaag blokkeert niet alleen het verzoek. Ze identificeert het veld en de regel die faalde, duidelijk genoeg voor een ontwikkelaar, operator of gebruiker om het te herstellen.

Conditionele vertakkingen verdienen hun eigen doorloop. Als een formulier vijf keuzes bevat die verschillende vervolgvelden onthullen, test dan alle vijf. Test ook het terugschakelen: een verborgen veld mag geen verouderde waarde blijven indienen nadat de gebruiker een eerdere antwoord heeft gewijzigd. Hier komt een artikel over documentstructuur en context samen met gewone software‑testing. Het begrijpen van relaties in het document is alleen nuttig als die relaties de serialisatie overleven.

De identiteit van een veld is belangrijker dan de bewoording van het veld. Labels veranderen voor duidelijkheid, vertaling en merkstem. Stabiele interne identifiers mogen niet veranderen mee. Een release‑check moet daarom het zichtbare label, de interne naam, het verwachte type en de bestemmingsmapping als afzonderlijke eigenschappen vergelijken.

Let op wat er gebeurt wanneer het ontvangende systeem niet beschikbaar is of de inzending afwijst. Behoudt het formulier het werk van de gebruiker? Probeert het veilig opnieuw, of maakt het duplicaten? Kan een operator de fout traceren zonder ruwe logbestanden te lezen? Gegevens die bewegen tussen documentverwerkingsworkflows en enterprise-systemen hebben een waarneembaar foutpad nodig, niet een succesmelding die wordt getoond voordat de overdracht voltooid is.

Wie bezit het contract na de lancering?

Contracttesten kunnen geen eenmalige opruiming zijn die net voor de release wordt uitgevoerd. Het formulier, het schema en de downstream‑interface blijven zich wijzigen.

Één team heeft duidelijke eigendom van het contract nodig, zelfs wanneer verschillende teams onderdelen van de workflow bezitten. Die eigenaar hoeft niet elke wijziging van de tekst goed te keuren. Wel moet hij weten welke wijzigingen ingediende gegevens kunnen beïnvloeden, welke tests moeten worden uitgevoerd en wie reageert wanneer validatiefouten optreden.

Versieer het schema met de formulierdefinitie. Voer representatieve contracttests uit in continue integratie telkens wanneer de template, prompt, formuliercode of API verandert. In productie moet je afgewezen inzendingen en mapping‑fouten monitoren per veld en contractversie. Een toename van één fout na een release is veel makkelijker te diagnosticeren dan een vage melding dat \”het formulier niet meer werkt\”.

Er is een grens aan wat schema‑validatie kan bewijzen. Het kan aantonen dat een waarde voldoet aan de opgegeven beperkingen. Het kan echter niet bewijzen dat de gebruiker de juiste waarde heeft gekozen, dat de bedrijfsregel logisch is of dat de workflow voldoet aan elke beveiligings‑, privacy‑, toegankelijkheids‑ of compliance‑vereiste. Teams hebben nog steeds beleidscontroles en menselijk oordeel nodig waar de consequenties dat rechtvaardigen.

Die voorbehoud verzwakt het argument voor een contract niet. Het definieert de taak van het contract.

Conclusie

AI kan de reis van een beschrijving naar een werkend formulier verkorten. Het kan ook een interface er afgewerkt laten uitzien voordat iemand de belofte erachter heeft getest.

De release‑beslissing moet gebaseerd zijn op expliciete veldsemantiek, contracttests die faalfases omvatten, en eigendom die later wijzigingen overleeft. Een schone interface is welkom. De moeilijkere vraag is de cruciale: kan elke geaccepteerde invoer correct worden geïnterpreteerd door het systeem dat het ontvangt?