Skip to main content

​
¿Qué es un output schema?

Un output schema define la estructura JSON exacta de los resultados devueltos por Omni. En lugar de recibir salidas crudas de los engines, obtiene resultados formateados exactamente como los necesitan sus sistemas.

​
Cómo definir un output schema

Los output schemas se definen como estructuras JSON dentro de la configuración del workflow. Cada campo se asigna a datos extraídos y verificados por los engines del workflow.

​
Guía de escritura del schema

Cuando configure el output schema en el Step 4 de creación del workflow, la UI aplica estas reglas:
  • Standard: sigue JSON Schema Draft-07 con restricciones adicionales de Omni.
  • Root shape: debe empezar con "type": "object" y definir campos bajo "properties".
  • Field types: puede usar string, number, integer, boolean, object y array.
  • Nesting depth: la anidación está limitada a 2 niveles.
  • Duplicate names: no se permiten nombres de campo duplicados.
  • description: añadir description en cada campo mejora la precisión de la IA.
  • Sync: Field Builder y JSON input se sincronizan automáticamente.
Field Builder vacío con guía de schema

Field Builder en Step 4 con la guía de escritura del schema.

JSON Schema Input

JSON Schema Input con un schema válido de Draft-07.

Ejemplo de output schema para KYB:

​
Verification status

Cada respuesta de análisis incluye en el nivel superior un verificationStatus asignado por el sistema, con uno de estos valores: verified, pending_review o rejected. El sistema determina este valor con independencia de su output schema.
Puede definir un campo con el mismo nombre dentro del bloque decision de su schema, pero ese es un valor definido por el usuario e independiente del veredicto del sistema. Alinearlo con el mismo enum simplifica el routing downstream.

​
Buenas prácticas

Diseñe el schema para que coincida con lo que esperan su backend o sus sistemas de compliance. Así evita transformaciones posteriores.
Añada siempre un bloque superior con result, verificationStatus (verified / pending_review / rejected) y razones. Es un patrón recomendado, no una estructura impuesta por el sistema. Alinearlo con el enum del sistema simplifica el routing.
Los schemas simples son más fáciles de mantener e integrar. Anide solo cuando los datos realmente lo requieran.

​
Ontology Mapper

El Ontology Mapper valida que las salidas de los engines se ajusten al schema definido. Si un engine devuelve datos en un formato distinto, el mapper los normaliza antes de entregarlos.