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. Te contesta bien mientras el proceso siga vivo, y pierde el hilo en cuanto lo reinicias.

Ninguna de esas paredes es teórica. Son, exactamente, lo que falta.

Este capítulo cambia de registro a propósito. No es un resumen 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 que confirman que el catálogo se sostiene en terrenos muy distintos.

Y, en el capítulo 29, 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 entre eso y una pieza de infraestructura que cualquiera pueda adoptar un martes por la tarde.

Lo organizo en cinco 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. La cláusula de rescisión que se activa en un contrato.

Todas tienen la misma forma: una condición sobre los hechos del grafo y algo que ocurre cuando esa 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).

El segundo medio paso ya está dado, y es la derivación. El prototipo calcula una magnitud a partir de otras respetando las unidades, y escribe el resultado con su calculado_de y su justificado_por puestos.

La regla vive en el grafo, no en el código: una expresión sobre roles y una unidad de destino. Así se calcula hoy el oro fino de la minera. De ahí sale que 2.480 t por 8,6 g/t den 685,7 onzas troy sin que nadie escriba el número.

El tercer medio paso cierra la validación. Las formas del capítulo 5 viven en el grafo como entidades y el evaluador las comprueba: rangos, cardinalidades, roles requeridos y unicidad.

No rechaza nada, porque el mundo abierto se mantiene. Anota la violación como un hecho y la cierra cuando el dato que la causaba se corrige.

La demostración está en el capítulo 19: una transferencia que excede el límite, se asienta igual y queda marcada.

Lo que ese motor todavía no es es un evaluador de reglas declarativas. Sabe ejecutar verbos, sabe calcular y sabe comprobar. No sabe resolver «si se cumplen estas condiciones sobre los hechos, deriva este hecho nuevo».

La regla del spa se almacena y no se dispara. Falta el disparo condicional con agregados: contar las siete sesiones y escribir la octava.

Y falta una clase de forma que la primera versión dejó fuera a propósito, la que recorre caminos («que no haya ciclos en causado_por»). Deja de ser una pasada lineal y cambia de clase de coste.

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 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 no es ponerla a ejecutar, sino a escribir.

Que un LLM traduzca una regla 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.

Un modelo bien definido vuelve esa traducción casi directa, porque los roles ya están tipados y la regla se corresponde con patrones sobre hechos canónicos.

Así se obtiene lo mejor de los dos mundos: la soltura del lenguaje natural para escribir reglas y el rigor del motor para ejecutarlas.

La IA entra dos veces: para convertir lenguaje en hechos, como vimos en el capítulo 26, y para traducir 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 el tiempo de validez. Cada hecho lleva su rango [inicio, fin), y una consulta «en el momento T» recupera lo que era cierto del mundo entonces.

Es la mecánica de vigencia que el libro reifica con rangos: la decisión D6 del capítulo 9.

El tiempo de registro, que anota cuándo el sistema afirmó cada hecho, tampoco falta del todo. Todo hecho entra con su marca sin que nadie la pida.

Y de ella depende algo que ya se usa a diario. Cuando un rol tiene varios valores, el vigente es el de marca más reciente, y el orden del historial sale de ahí. Sin esa marca, corregir no sabría cuál de las dos versiones es la buena.

Lo que falta es más estrecho y más incómodo de lo que suele decirse: esa marca no sobrevive al reinicio.

Al recargar desde disco, los hechos vuelven con una marca nueva, la del momento de la recarga, y las originales se pierden. El sistema recuerda qué creía, pero olvida desde cuándo lo creía.

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 conservó esa versión pasajera. 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.

Hay además un segundo respaldo de otra naturaleza. El servidor MCP escribe un registro de eventos que solo crece, y reconstruye el universo reproduciéndolo al arrancar.

Guarda las llamadas, no el estado. Y eso tiene una virtud que la tabla no tiene: la vigencia viaja dentro de los argumentos y vuelve intacta.

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 diaria es alta, nadie la adopta.

La regla es vieja y cruel: la mejor idea con malas herramientas pierde frente a la idea mediocre con buenas herramientas. Aquí está la lista, ordenada por prioridad.

4.1 — Ingestor de lexicon. Hoy las entradas del lexicon se escriben a mano. Hace falta una herramienta que las importe desde recursos ya construidos: FrameNet(14), VerbNet(15), PropBank.

Eso da, de un golpe, un piso de miles de verbos sin trabajo manual.

4.2 — Analizador de lenguaje natural a hechos. Hoy ese trabajo lo hace un LLM invocando funciones. Hace falta también uno local y determinista.

Para textos donde la latencia del modelo importa, como los sistemas en tiempo real. O donde la privacidad lo exige, como los datos médicos que no deben salir de la sala. Combinar análisis sintáctico con el lexicon es trabajo concreto, no investigación abierta.

4.3 — Inspector y entorno de trabajo. El experimento reflexivo entregó una primera versión: un inspector que, junto a cada vista, muestra las tripletas que la sostienen. Lo que ves es el dato.

Falta el resto. Explorar individuos y vecinos a voluntad. Consultar con patrones. Seguir la cadena causado_por o justificado_por de cualquier nodo.

Y falta la pieza que el propio experimento señaló: vistas con nombre definidas como dato, para volver a concretar el grafo sin ahogar al modelador en la abstracción. La base existe. El salto es de semanas, no de meses.

4.4 — Validador de migración. Cuando un sistema heredado quiere migrar, hay que comprobar que su dialecto encaja con el catálogo.

Una herramienta de validación detecta los cuellos: roles sin firma, ejes ambiguos, vigencias que se contradicen. El paso «el dato registra su propia firma», que la prueba reflexiva ya introdujo, la vuelve más fácil.

4.5 — Generador de servidor MCP. Dado un lexicon, generar solo el servidor MCP correspondiente. Eso convierte cada dominio en un asistente conversacional sin escribir código de pegamento.

Trabajo de pocas semanas, con un impacto enorme en la adopción: baja a casi cero el costo de probar la propuesta con datos propios.

Frente 5 — Comunidad y gobernanza

Aquí entramos en la pieza que el autor no controla. Para volverse útil más allá de un libro, WQuestions necesita comunidad. Gente modelando dominios, aportando lexicon, reportando fricciones, escribiendo herramientas, adoptándolo en proyectos reales.

Una arquitectura sin comunidad es una idea bonita en un PDF. Con comunidad, es infraestructura. Esa 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 cinco frentes juntos, como capas de una misma pila. Cada capa puede avanzar por su cuenta: cambiar el respaldo de persistencia no obliga a tocar el lexicon, y mejorar el motor de reglas no altera lo 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 se miden por madurez, el panorama es claro y no desalentador. Tres tienen un piso operable: persistencia, una primera versión del inspector y el medio paso del motor. Dos están casi por construir: la comunidad y las herramientas completas.

Nada está en cero. Nada está cerca de cien.

Las fricciones documentadas que siguen abiertas

Además de los cinco frentes mayores, el prototipo dejó al descubierto algunas fricciones puntuales del catálogo al chocar con los dominios de estrés.

El experimento reflexivo (capítulo 29) cerró varias: el texto libre, el tipado de los campos definidos por datos, la presentación derivada de hechos.

Y entregó el comodín V, cualquier eje de valor, que resuelve de raíz toda la familia «esta firma es demasiado estrecha». Lo que queda abierto es esto:

Ninguna de estas fricciones bloquea el modelo, y se repite un patrón. Las del tipo «firma demasiado estrecha» se resuelven con el comodín V que el experimento ya introdujo. Varias otras quedan cubiertas por roles de dominio.

Es la lista de mejoras concretas. Se alarga 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 exponían una idea con la claridad suficiente para que otros se la apropiaran y la empujaran adelante.

Ninguna nació completa. Todas nacieron legibles.

Ahí está 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 firma demasiado estrecha. La propuesta aguanta el peso que prometió aguantar.

Desde aquí, la tarea no es demostrarla, porque ya está demostrada en lo esencial. Es 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.