Esquemas estrictos y validación de formato

Hay tres preguntas distintas sobre una salida estructurada, y conviene no mezclarlas. La primera es si está bien formada: si es JSON que se puede leer. Muchos proveedores ofrecen un modo que lo garantiza, y ayuda, pero solo responde a esa pregunta. La segunda es si es válida: si cumple el esquema, con los campos obligatorios, los tipos correctos, los valores de la lista permitida, las longitudes y nada más. La tercera es si está permitida: si ese usuario puede pedir esa acción sobre ese caso, que se responde consultando datos, como viste en el módulo 15.

Un esquema estricto se ocupa de la segunda pregunta con todo el rigor posible: enumera los valores aceptables en vez de aceptar texto libre, prohíbe los campos que no declara y no convierte tipos por su cuenta. Cada campo libre que se deja es una puerta para que la salida lleve algo que el sistema de destino no esperaba.

Un validador que acepta campos adicionales parece inofensivo: el campo de más no lo usa nadie. El problema es cuando sí se usa, porque el sistema de destino guarda el objeto entero y algún componente lee ese campo. Así, un campo que el modelo inventó (o que un documento le sugirió) termina cambiando a quién se asigna una tarea, su prioridad o su visibilidad, sin que nadie lo haya diseñado.

Lee cómo se comporta el validador actual y busca en las salidas de la semana el campo que no está en el esquema y que, aun así, se guardó en la tarea.

Para decidir si se cambia el validador, nada convence más que aplicar el esquema propuesto a salidas que ya pasaron. Cada salida aceptada hoy se mira contra cada regla del esquema estricto: tipo de tarea de la lista, número de siniestro con su formato, resumen dentro de la longitud, prioridad de la lista, ningún campo adicional y JSON completo sin reparar.

Cuenta cuántas de las salidas que el validador actual aceptó habría rechazado el esquema estricto. La que el actual ya rechazó no cuenta.

Algunos validadores, ante una salida defectuosa, intentan arreglarla: convierten un texto en número, recortan lo que sobra, completan un JSON que llegó cortado. Parece amable y es peligroso, por dos razones. La primera, que lo que resulta no es lo que el modelo produjo ni lo que el esquema describe, sino una tercera cosa que nadie revisó. La segunda, que esconde el fallo: el registro dice «aceptada» y nadie se entera de que el modelo está devolviendo salidas rotas.

Busca en el registro la salida que el validador actual dio por buena después de arreglarla.

La regla es fallar cerrado: si la salida no cumple el esquema, no se usa, ni completa ni en parte. Se registra el motivo del rechazo (sin guardar más texto del necesario), se puede reintentar una vez pidiendo al modelo la misma tarea, y si vuelve a fallar el caso pasa a una persona con el motivo a la vista. Los rechazos se cuentan: un aumento brusco es una señal de que algo cambió en el modelo, en las instrucciones o en los documentos que entran.