Qué falta

Imagina que cierras este libro y decides que la idea merece existir de verdad. Clonas el repositorio, levantas el prototipo, cargas un dominio propio (tu spa, tu clínica, el sistema de tu empresa) y empiezas a registrar hechos. Funciona: los hechos entran como tripletas tipadas, el lexicon traduce tu vocabulario, las consultas responden. Y entonces, casi de inmediato, chocas con una pared. Quieres que el sistema dispare solo la regla «a la séptima sesión, la octava es gratis»; el prototipo guarda la regla como dato, pero no la ejecuta. Quieres preguntarle no qué era cierto, sino qué sabía el sistema en abril; la respuesta a medias te dice que esa versión del pasado no se conservó. Ninguna de esas paredes es teórica. Son, exactamente, lo que falta.

Este capítulo cambia de registro a propósito. No es una recapitulación ni una mirada inspiradora al horizonte; es un mapa de implementación. Hasta aquí el libro presentó la propuesta entera y la sometió a prueba: un prototipo en Python con sus pruebas en verde, ocho dominios industriales modelados que confirman que el catálogo se sostiene en territorios disímiles y (en el capítulo 28) el experimento reflexivo, donde el modelo bastó para describir su propia herramienta y se corrigió a sí mismo bajo carga. Lo que sigue es el inventario de la distancia que separa eso de una pieza de infraestructura que cualquiera pueda adoptar un martes por la tarde.

Lo organizo en seis frentes. De cada uno digo tres cosas: qué falta, qué tan urgente es y qué requiere para resolverlo. Donde el experimento reflexivo ya adelantó terreno lo señalo, porque eso mueve el punto de partida. Y cierro con la pieza que pesa más que todas las demás juntas, y que el autor no controla solo.

Frente 1 — El motor de inferencia

Apareció una y otra vez a lo largo del libro: el evaluador externo que recorre el grafo y dispara reglas. La regla «siete sesiones cumplidas, la octava gratis» del spa. La verificación «prescripción contra contraindicación» de la clínica. El cálculo del marcador a partir de cada gol del partido. La cláusula de rescisión que se activa en un contrato. Todas comparten la misma forma estructural: una condición declarativa sobre los hechos del grafo y un consecuente que se efectúa cuando la condición se cumple.

El experimento reflexivo dio el primer medio paso: demostró que la conducta puede vivir como dato y ejecutarse desde afuera (un evaluador genérico que despacha verbos leyéndolos del grafo). Lo que ese motor todavía no es es un evaluador de reglas declarativas. Sabe ejecutar verbos; no sabe resolver «si se cumplen estas condiciones sobre los hechos, deriva este hecho nuevo». Esa es la pieza ausente.

Hay al menos cuatro tecnologías candidatas para esa capa, cada una con su fortaleza y su flanco débil:

El lugar de la IA en este frente

La cuarta opción de la lista (usar un modelo de lenguaje) merece una aclaración, porque la tentación es grande. ¿No podría una IA, incluso de pesos abiertos y autoalojada, hacer de motor de inferencia, con un buen prompt y un modelo bien definido? Hay que separar dos clases de regla. Para las borrosas (¿este reclamo es urgente?, ¿este texto implica consentimiento?) la respuesta es sí, y ahí el LLM es la herramienta correcta. Para las estrictas (las del spa, las del banco, las del contrato) la respuesta es no, por cuatro razones que ningún prompt arregla.

La forma productiva de sumar IA, entonces, no es ponerla de runtime sino de autor. Que un LLM compile una regla escrita en lenguaje natural («a las siete sesiones, la octava es gratis») a una regla declarativa en Datalog o SHACL sobre los hechos del grafo, y que el motor determinista la ejecute. El modelo bien definido vuelve esa compilación casi directa, porque los roles ya están tipados y la regla mapea a patrones sobre hechos canónicos. Así se obtiene lo mejor de los dos mundos: la flexibilidad del lenguaje natural para escribir reglas y el rigor del motor para ejecutarlas. La IA entra dos veces —para convertir lenguaje en hechos (lo vimos en el capítulo 26) y para compilar reglas—, pero el corazón de la inferencia estricta queda determinista y demostrable.

En concreto, esa compilación se ve así. El modelo recibe la regla en español y el catálogo tipado, y emite una regla declarativa que el motor ejecutará por su cuenta:

SISTEMA. Compila la regla de negocio a Datalog sobre hechos WQuestions
(sujeto, rol, valor). No la ejecutes; solo compílala.

Catálogo: servicio_spa(S) con roles cliente, estatus_factual.
Regla: "A las siete sesiones finalizadas de un cliente, la octava es gratis."

sesion_ok(C, S)  :- instancia_de(S, servicio_spa),
                    cliente(S, C), estatus_factual(S, finalizada).
octava_gratis(C) :- count{ S : sesion_ok(C, S) } >= 7.

El modelo de lenguaje escribió la regla; el motor determinista la ejecuta y firma cada hecho derivado. La IA nunca toca el dato en caliente. Y el hecho derivado entra al grafo con la misma forma que cualquier otro: una tripleta tipada, con su autor y su vigencia.

Frente 2 — Bitemporalidad completa

Hoy el modelo soporta tiempo de validez (valid time): cada hecho lleva su rango [inicio, fin), y una consulta «en el momento T» recupera lo que era cierto del mundo entonces. Esta es la mecánica de vigencia que el libro reifica con rangos (la decisión D6, enunciada en el capítulo 9). Lo que falta es el tiempo de transacción (transaction time): cuándo el sistema afirmó ese hecho.

La diferencia importa cuando alguien pregunta no «¿qué era cierto?» sino «¿qué sabíamos?». Toma un caso del banco. En mayo registramos que el plan mensual de un cliente venció el 31 de marzo; en abril el cliente aparece, demuestra que había renovado y retrocedemos el plan. La pregunta del auditor («¿qué estaba en el sistema entre el 1 de abril y la fecha de la corrección?») solo se responde si el sistema preservó esa versión transitoria, la que era falsa pero estuvo vigente como creencia del sistema durante semanas.

Frente 3 — Persistencia industrial

El experimento reflexivo cambió el punto de partida de este frente: el prototipo ya no vive solo en memoria. Su capa de persistencia guarda individuos y hechos en SQLite y los recarga al arrancar. Bastan dos tablas: una de individuos (id, eje, payload_json) y una de hechos (sujeto, rol, valor, inicio, fin, …). Es la prueba de que el modelo persiste sin esfuerzo: la geometría de las tripletas se aplana a tabla casi sin pérdida.

Lo que falta, entonces, no es «persistencia» (ya existe) sino persistencia industrial y plural: una interfaz Storage abstracta de la que SQLite sea la primera implementación, y otros respaldos con perfiles distintos según el caso de uso.

Frente 4 — Tooling

Una propuesta como WQuestions vive o muere por sus herramientas. Los conceptos pueden ser impecables; si la fricción operativa es alta, nadie la adopta. La regla es vieja y cruel: la mejor idea con mal tooling pierde frente a la idea mediocre con buen tooling. Aquí está la lista, ordenada por prioridad.

Frente 5 — Lexicon poblado en varios idiomas

El catálogo canónico del libro (la decisión D8, que hace invisible el catálogo y deja al lexicon como única interfaz) define 38 roles. El lexicon del prototipo registra una decena de verbos. Para un sistema productivo, el lexicon de un solo idioma necesita del orden de dos a cinco mil entradas: los verbos frecuentes del español, sus formas nominales, las locuciones idiomáticas que la gente usa sin pensar.

Lo que falta es trabajo lingüístico paciente. Por dominio o por familia semántica (transferencia, comunicación, movimiento, percepción, estados) hay que poblar el lexicon. FrameNet español, el corpus español de Universal Dependencies y AnCora son fuentes legítimas para mecanizar parcialmente la tarea, pero no para eliminar el juicio humano que cada entrada delicada exige.

Para la internacionalización, cada idioma necesita su propio lexicon, pero no su propio catálogo: la espina es común y solo cambia la piel que la traduce. Esto es, a la vez, una oportunidad y una carga. Oportunidad, porque un dominio modelado en español queda inmediatamente disponible en cualquier idioma que tenga su lexicon. Carga, porque cada idioma nuevo es un proyecto léxico sostenido, no un fin de semana.

Frente 6 — Comunidad y gobernanza

Aquí entramos en la pieza que el autor no controla. WQuestions, para volverse útil más allá de un libro, necesita comunidad: gente modelando dominios, contribuyendo lexicon, reportando fricciones, escribiendo herramientas, adoptándolo en proyectos reales. Una arquitectura sin comunidad es una idea bonita en un PDF; una arquitectura con comunidad es infraestructura. La diferencia no la firma el autor, la firman los demás.

Qué falta, en concreto:

• Repositorio canónico abierto, con licencia permisiva. Una primera versión ya vive en un repositorio público mientras lees esto.
• Proceso de contribución: cómo proponer nuevas entradas al catálogo, nuevos dominios al lexicon, parches al motor. Necesita criterios escritos, no costumbres tácitas.
• Foro o canal de discusión para resolver las fricciones que surjan al modelar dominios nuevos. Cada conversación cualifica el catálogo (y el experimento reflexivo es evidencia de que las fricciones más valiosas aparecen cuando se somete el modelo a una carga real).
• Estandarización gradual: una vez que varios proyectos adopten el modelo, vale la pena llevar las partes más universales del catálogo a un proceso formal (IETF, W3C, ISO). Eso da estabilidad legal para el uso empresarial.
• Dialectos de dominio mantenidos por comunidades sectoriales (clínico, financiero, legal, manufactura), cada uno con su propia gobernanza dentro de la espina común.

Las arquitecturas duraderas no se imponen: se adoptan. Y se adoptan cuando alguien que no es su autor decide que vale la pena empujarlas.La pieza que el autor no controla

La pila completa

Conviene ver los seis frentes juntos, como capas de una misma pila. Cada capa puede evolucionar por su cuenta (cambiar el respaldo de persistencia no obliga a tocar el lexicon, y mejorar el motor de reglas no altera la aplicación que ve el usuario). Esa independencia es, en sí misma, una propiedad de diseño: el modelo del medio es el contrato estable que sostiene todo lo demás.

Y si los seis frentes se miden por su grado de madurez, el panorama es claro y no desalentador. Tres de ellos tienen un piso operable (persistencia, una primera versión de inspector, el medio paso del motor); tres están casi por construir (el lexicon a escala, la comunidad, el tooling completo). Nada está en cero; nada está cerca de cien.

Las fricciones documentadas que siguen abiertas

Además de los seis frentes mayores, el prototipo expuso un puñado de fricciones puntuales del catálogo al chocar con los dominios de estrés. El experimento reflexivo (capítulo 28) cerró varias (el texto libre, el tipado de los campos definidos por datos, el display derivado de hechos) y entregó el comodín V (cualquier eje de valor), que resuelve de raíz toda la familia «esta signatura es demasiado estrecha». Lo que queda abierto es esto:

Ninguna de estas fricciones bloquea el funcionamiento del modelo, y se repite un patrón: las relajaciones del tipo «signatura demasiado estrecha» se resuelven con el comodín V que el experimento ya introdujo, y varias otras quedan cubiertas por roles de dominio bajo la política liberal del catálogo. Es la lista de mejoras concretas: se acumula a medida que el modelo se prueba en territorios nuevos y se acorta a medida que se lo somete a cargas exigentes. Una lista que crece y mengua a la vez es exactamente lo que cabe esperar de una arquitectura viva.

El libro como semilla

Cerremos con la idea menos técnica del capítulo. Un libro no es una propuesta terminada: es una invitación a que alguien la termine. Las arquitecturas que duraron (Unix, TCP/IP, HTTP, SQL, RDF) empezaron como artículos, manifiestos, RFCs, libros: textos que articulaban una idea con la claridad suficiente para que otros pudieran apropiársela y empujarla adelante. Ninguna nació completa; todas nacieron legibles.

Eso es lo que hace la diferencia entre una especulación y una semilla. El modelo bastó para describir su propio menú, sus formularios, sus esquemas y su conducta, y para corregirse cuando la carga reveló una signatura demasiado estrecha. La propuesta aguanta el peso que prometió aguantar. Desde aquí, la tarea no es demostrarla (ya está demostrada en lo esencial), sino perfeccionarla: poblar el lexicon, montar el motor, escribir las herramientas, formar la comunidad. Trabajo, no misterio.

El catálogo está incompleto, el lexicon bosquejado, las herramientas embrionarias. Pero la propuesta funciona aplicada a sí misma. Lo que falta es construirla, no descubrirla.El estado del proyecto

Queda una sola página antes del cierre, y es la que responde la pregunta que ha estado latiendo bajo todo el libro: si esto es tanto trabajo, ¿por qué vale la pena? Por qué importan, a fin de cuentas, las preguntas.