Propósito El Modelo JSON Canónico define la representación estable y determinista del estado de ejecución de IA generado por un sistema compatible con FACET. Su objetivo es garantizar que entradas idénticas produzcan salidas JSON idénticas byte por byte, que sean comparables, cacheables, diffables y reproducibles, y que los formatos específicos de proveedor no introduzcan nondeterminismo en sistemas aguas abajo. JSON Canónico es el artefacto límite entre la compilación determinista y la ejecución probabilística del modelo.
Por qué es necesario Los stacks modernos de grandes modelos de lenguaje sufren nondeterminismo oculto como reordenamiento de campos en objetos JSON, aparición o desaparición de campos opcionales, formatos de mensajes específicos de proveedor, streaming frente a no streaming, deriva estructural y valores por defecto implícitos aplicados en tiempo de ejecución. Estos efectos hacen que la cache sea poco fiable, la reproducción imposible, las pruebas de regresión sin sentido y la auditoría frágil. JSON Canónico elimina estos modos de fallo imponiendo una única forma normalizada.
Definición Un Documento JSON Canónico es un objeto JSON que satisface lo siguiente: orden determinista de campos, presencia explícita o ausencia de todos los campos opcionales, codificación estable de números y cadenas, estructura agnóstica al proveedor y totalmente derivada de un estado de ejecución tipado. FACET trata JSON Canónico como un artefacto compilado, no como una mera conveniencia de serialización.
Reglas de ordenamiento FACET aplica un orden estricto a nivel superior: meta system tools examples history user assistant output. Este orden es normativo y MUST ser preservado por todas las implementaciones compatibles. Los objetos anidados siguen orden lexical de claves en UTF-8 por punto Unicode y listas estables derivadas del orden de ejecución o claves explícitas.
Reglas de explícito JSON Canónico prohíbe valores por defecto implícitos y ambigüedad estructural. Reglas principales: campos opcionales definidos en el esquema pero ausentes en tiempo de ejecución MUST representarse explícitamente como null. La omisión de campos conocidos está PROHIBIDA. Listas vacías MUST representarse como []. Objetos vacíos MUST representarse como {}. Booleanos MUST ser siempre explícitos true o false. La representación explícita con null garantiza que la forma JSON permanezca constante independientemente del contenido, permitiendo verificación de forma O(1) y hashing estable entre lenguajes con diferentes comportamientos por defecto.
Normalización de números y cadenas Para evitar deriva entre plataformas: enteros sin ceros a la izquierda, flotantes en forma decimal normalizada sin exponente salvo que sea necesario, cadenas en UTF-8 normalizadas en NFC. El escape sigue el estándar JSON y las implementaciones MUST NOT emitir NaN o Infinity ni formatos numéricos dependientes de la configuración regional.
Relación con las fases de ejecución FACET JSON Canónico se produce al final de la Fase 5 Render. Entradas: AST tipado, mapa de variables computadas, layout final del Token Box, esquemas de interfaz. Salidas: un documento JSON canónico único sin ambigüedad sobre estructura o significado. Cualquier violación en esta etapa MUST abortar la ejecución en lugar de emitir un resultado no canónico.
JSON Canónico frente a cargas de proveedor El flujo es .facet hacia AST hacia R-DAG hacia Token Box con un núcleo que produce IR JSON CANÓNICO. Las cargas de proveedor como OpenAI, Anthropic o Gemini son vistas derivadas del JSON Canónico, no fuentes de verdad. JSON Canónico es la única fuente de verdad; las cargas de proveedor son vistas desechables generadas justo a tiempo.
Prevención de vendor lock-in JSON Canónico establece una frontera arquitectónica entre lo que el sistema decidió y cómo un proveedor espera recibirlo. FACET aplica la regla: todas las cargas de proveedor son efímeras. JSON Canónico es permanente. Esto permite cambiar de proveedor sin invalidar el historial, mantener ejecuciones reproducibles aunque cambie la API de un proveedor, asegurar auditorías frente a deriva de esquemas y evitar que bugs en adaptadores corrompan el registro central. En la práctica JSON Canónico se almacena, hashea, difiere y cachea; las cargas de proveedor se generan y descartan.
Contención de fallos Si un proveedor rechaza una carga, aplica restricciones no documentadas o cambia semánticas de streaming, el fallo queda aislado en la capa adaptadora. JSON Canónico permanece válido y reutilizable, lo que permite a sistemas FACET sobrevivir a cambios de API sin reescribir la lógica del agente.
Pruebas con snapshot JSON Canónico habilita pruebas de snapshot reales para sistemas de IA. Al ser determinista byte por byte, agnóstico al proveedor y completamente explícito, puede usarse como artefacto dorado. En pruebas FACET la canalización completa se ejecuta en modo puro, se produce JSON Canónico y se almacena o hashea como snapshot para comparaciones futuras. Esto hace que cambios lógicos sean visibles de inmediato y que la deriva de proveedores no invalide las pruebas.
Impacto empresarial Para empresas esto habilita pipelines CI deterministas, registros de ejecución aptos para auditoría, análisis reproducible de incidentes y cacheado a largo plazo con garantías criptográficas. JSON Canónico convierte el comportamiento de IA en artefactos versionados y probables, no en salidas efímeras.
Garantías de determinismo Si se cumplen: mismo documento FACET, mismas entradas, mismo modo de ejecución Pure y mismo registro de lentes, entonces JSON Canónico MUST ser idéntico y Hash(canonical_json) MUST ser idéntico. El comportamiento aguas abajo MUST ser reproducible. Esta es la base para memoization, pruebas de snapshot y agentes deterministas.
Comparativa Propiedad Ad-hoc JSON JSON Canónico orden de campos inestable determinista campos opcionales implícitos explícitos fuga de proveedor alta none fácil de diff no yes cache seguro no yes reproducible no yes
Principio de diseño JSON no es solo un formato de datos sino una frontera semántica. JSON Canónico convierte esa frontera en algo que puede ser razonado, probado y confiado.
Analogía con LLVM En el contexto industrial FACET JSON Canónico juega el mismo papel que LLVM IR en compiladores: representación independiente del proveedor, forma estable y determinista, diffable e inspeccionable, segura para optimización, cache y replay. Así como LLVM permite un objetivo x86, ARM o WebAssembly desde el mismo código fuente, FACET permite a una arquitectura de agente dirigirse a múltiples proveedores de LLM sin cambiar la semántica de ejecución.
Estado Este documento define el Modelo JSON Canónico normativo para FACET v2.0 y posteriores. Todas las implementaciones compatibles MUST seguir estas reglas al producir salida canónica de ejecución.
Sobre Q2BSTUDIO En Q2BSTUDIO somos una empresa de desarrollo de software especializada en aplicaciones a medida y software a medida, con experiencia en inteligencia artificial para empresas, ciberseguridad y servicios cloud aws y azure. Diseñamos soluciones de inteligencia de negocio y power bi para transformar datos en decisiones, y desarrollamos agentes IA y automatizaciones adaptadas a procesos concretos. Si busca desarrollar una solución personalizada visite nuestra página de desarrollo de aplicaciones y software multiplataforma en desarrollo de aplicaciones y software multiplataforma o explore nuestras capacidades de inteligencia artificial en servicios de inteligencia artificial. Además ofrecemos servicios de ciberseguridad, pentesting y arquitecturas cloud para garantizar despliegues seguros y escalables.
Palabras clave aplicaciones a medida software a medida inteligencia artificial ciberseguridad servicios cloud aws y azure servicios inteligencia de negocio ia para empresas agentes IA power bi