La prueba reflexiva

Imagina una pantalla partida en dos.

A la izquierda, una aplicación de gestión como cualquier otra: un menú lateral, un formulario de venta, una grilla con los últimos registros. Nada que un programador no haya construido cien veces.

A la derecha, una lista que crece a cada clic. Cada línea afirma una cosa mínima: «la venta tiene un campo llamado monto». Y debajo otra, y otra.

Esa lista no describe la aplicación de la izquierda.

Esa lista es la aplicación.

Hasta aquí, el libro ha apretado a WQuestions siempre desde fuera: el lenguaje, ocho dominios industriales, un sistema real en producción, cuatro casos elegidos para que crujiera.

Siempre la misma prueba. El modelo describe un mundo, y nosotros miramos si ese mundo cabe.

Falta una prueba, y es la más incómoda.

Pedirle al modelo que se describa a sí mismo.

Ya no un mundo ajeno, sino la herramienta misma. Un programa con sus menús, sus formularios y sus reglas, donde todo eso (lo que el programa es y lo que el programa hace) sea también un montón de hechos WQuestions.

Si las preguntas son la base de toda la información, la máquina que maneja información tendría que poder decirse en preguntas.

Este capítulo cuenta qué pasó cuando lo intentamos. Qué resistió. Qué tuvo que doblarse para aguantar la carga. Qué costuras quedaron a la vista.

Una aplicación hecha de preguntas

Construimos sobre el prototipo una aplicación de gestión pequeña: un menú navegable, formularios para dar de alta y editar, grillas para consultar, y entidades de negocio (personas, productos, ventas, compras) con sus campos.

Lo interesante no es la aplicación. Es de qué está hecha.

Cada cosa que se ve en pantalla está ahí porque hay un hecho que la afirma. Un hecho de tres piezas: (sujeto, rol, valor).

Un menú no es una pieza programada. Es un puñado de relaciones. Cada opción del menú lleva una acción, y cada acción dice de qué tipo es: mostrar un texto, abrir un formulario, abrir una grilla, guardar. El motor conoce esos verbos y sabe qué hacer con cada uno.

Con la forma de las entidades pasa lo mismo:

• una entidad tiene campos
• un campo tiene una etiqueta
• un campo tiene un tipo
• un campo tiene un orden

Nada de esto vive fuera del grafo. No hay una tabla venta con sus columnas fijas, ni una plantilla de formulario escrita a mano. Hay hechos, y un motor que los lee.

Escrito con los nombres que usa el prototipo, el menú se ve así:

(menu_principal, instancia_de, menu)             ∈ M(O, K)
(menu_principal, tiene_opcion, opcion_ventas)    ∈ M(O, O)
(opcion_ventas,  etiqueta,     "Ventas")         ∈ M(O, K)
(opcion_ventas,  tiene_accion, abrir_grilla_venta) ∈ M(O, O)
(abrir_grilla_venta, instancia_de, abrir_grilla) ∈ M(O, K)
(abrir_grilla_venta, sobre,        venta)         ∈ M(O, K)

Eso se nota en la pantalla, en el panel de la derecha con el que abrió el capítulo.

Al lado de cada vista, un inspector muestra las tripletas que la sostienen. Lo que ves es lo que hay en el grafo.

La interfaz no traduce una base de datos a botones. La interfaz emerge del grafo.

Lo que ves en la pantalla es, sin intermediarios, lo que hay en el grafo.El principio del inspector

La prueba reina

Toda la apuesta cabe en una sola operación.

Si la estructura y el comportamiento son de verdad datos, agregar estructura debería costar hechos, no código.

Ahí está la prueba: ¿cuánto cuesta añadir un campo nuevo a una entidad que ya existe?

Lo medimos en vivo, con el sistema corriendo. Agregamos el campo «Documento» a la entidad venta. Definimos cinco tripletas, y nada más:

(campo_venta_documento, instancia_de, campo)   ∈ M(O, K)
(venta, tiene_campo, campo_venta_documento)    ∈ M(K, O)
(campo_venta_documento, tipo_dato, texto)      ∈ M(O, K)
(campo_venta_documento, orden, 5)              ∈ M(O, N)
(campo_venta_documento, rol, documento)        ∈ M(O, K)

Cinco tripletas. Ni una línea de código en el motor, en el servidor ni en la interfaz.

Al recargar, el resultado apareció solo:

• el formulario dibujó el campo
• la grilla le sumó la columna
• el guardado lo persistió

Las tres cosas leen el esquema del grafo en vez de saberlo de antemano.

Cinco hechos, cero código. Ese es el resultado del experimento, y la confirmación más limpia de la primera mitad de la tesis.

La estructura es dato.

Lo que la carga confirmó

Más allá del número, el experimento puso a prueba tres ideas que el libro había defendido en la pizarra. Las tres aguantaron en el terreno.

El comportamiento también es dato

No hay lógica escrita para cada caso. Hay un motor que lee e interpreta.

Una y otra vez apareció en estas páginas la figura del evaluador externo: un motor que recorre el grafo y hace lo que los hechos dicen. El grafo guarda; el motor actúa. Nunca se mezclan.

Aquí dejó de ser una promesa y pasó a ser código que corre.

Es un repartidor que no sabe nada de ventas ni de compras. Recibe una acción, mira de qué tipo es y se la pasa a quien sabe ejecutarla.

def ejecutar(self, accion):
    """El motor no sabe qué es 'venta' ni 'compra'.
    Lee el verbo de la acción y delega en el manejador del verbo."""
    verbo = self.grafo.objeto(accion, "instancia_de")     # p.ej. abrir_grilla
    manejador = self.verbos[verbo]                          # tabla genérica
    objetivo = self.grafo.objeto(accion, "sobre")          # p.ej. venta
    return manejador(objetivo)                              # nada cableado

# Agregar la transacción "compras" no toca este código:
# basta declarar el verbo, la entidad y sus campos como hechos.

Agregar una transacción entera nueva («compras», hermana de «ventas») costó datos y casi nada de motor.

El comportamiento vive en el grafo y se interpreta desde afuera, tal como el modelo prometía.

El grafo compartido cae solo

El capítulo 1 abrió con la torre de Babel: cada sistema con su esquema, sordo al de al lado. El antídoto del libro es un único piso de hechos donde las entidades se reúsan.

Lo comprobamos con «cliente» y «proveedor». No son dos tipos de persona. Son el papel que alguien juega en una venta o en una compra. Es la agencia contextual de la decisión D5 en acción.

La misma persona, ana, es cliente de una venta y proveedora de una compra sin duplicarse. Un individuo, dos papeles.

El anti-Babel no hubo que forzarlo. Cayó solo en cuanto dejamos de tratar el rol como si fuera un tipo.

La vigencia es la forma natural del «editar»

Al usar la aplicación notamos algo revelador: la edición de datos se había implementado sin borrar absolutamente nada.

Editar un valor en un formulario es asentar un hecho nuevo y leer el más reciente.

Es la vigencia de la decisión D6 funcionando en la práctica. El historial sale gratis, y ningún dato nuevo pisa al viejo.

Y resultó ser la forma natural de hacer lo que en cualquier programa se llama «editar». No un añadido teórico que hubiera que justificar a la fuerza.

La auto-corrección: cuando el sistema nos detuvo

El experimento no solo nos dio la razón. También nos acorraló.

Vale la pena contarlo, porque es el método del libro operando sobre sí mismo.

Queríamos clasificar a una persona. Decir «Ana es un cliente», que en tripletas se escribe (ana, instancia_de, cliente).

El sistema nos detuvo.

La regla que habíamos diseñado para instancia_de exigía que el sujeto viniera del eje O, el de las situaciones. Pero Ana no es una situación. Es una persona, y las personas viven en Q.

Lo irónico es que este mismo libro, en el capítulo 3, ya escribía sin parpadear hechos como estos:

(vendedor_17,    instancia_de, profesion_vendedor) ∈ M(Q, K)
(municipalidad_centro, instancia_de, organizacion) ∈ M(Q, K)
(tienda_central, instancia_de, punto_de_venta)     ∈ M(L, K)
(camiseta_88,    instancia_de, camiseta)           ∈ M(O, K)

Sujetos en Q, en L, en O. La teoría siempre dio por hecho que clasificar es una operación universal.

El prototipo estaba, sencillamente, detrás de su propia teoría.

La presión nos obligó a inventar un comodín, la letra V, y a reescribir la regla con él: la de instancia_de pasó de O→K a V→K.

Ese comodín no arregla solo este caso. Es la misma llave que el capítulo 31 pide para aflojar otras reglas demasiado estrechas: paciente o partes, hoy fijadas a O→Q cuando deberían admitir O→V.

La fricción, sometida a carga, no abrió un agujero en el modelo. Lo empujó a alinearse con lo que ya afirmaba de antemano.

La presión no abrió un agujero en el modelo: lo empujó a alinearse con lo que ya afirmaba.Sobre la auto-corrección

Las fricciones nuevas: dos cerradas, una abierta

La presión reflexiva destapó tres fronteras que los ocho dominios industriales no habían tocado.

Dos las cerramos dentro del mismo experimento. La tercera sigue abierta.

El texto libre. Los siete ejes responden a preguntas, no a tipos de programación. No existe un eje «texto».

Un nombre como «Ana», el cuerpo de un mensaje, el número de un documento: letras sueltas, sin casa propia.

Decidimos guardarlas en K como un literal: un nodo que se acuña en el momento y no se comparte con nadie. Así, dos personas que se llaman «Ana» no acaban siendo la misma.

El catálogo como dato. El catálogo del modelo vigila con rigor sus propios roles. Los campos que el usuario inventa sobre la marcha pasaban sin que nadie los revisara.

La carga lo dejó a la vista: la mitad de esas reglas seguía viviendo en el código.

Lo cerramos haciendo que cada campo diga por sí mismo qué se le puede escribir: de dónde sale el sujeto y qué clase de valor admite. Un campo inventado se revisa hoy igual que uno de los que trae el modelo de fábrica.

El usuario nunca ve ese catálogo: lo que ve es el lexicon, como fija la decisión D8. Pero esta prueba lo obligó a cubrir también lo que el usuario inventa mientras trabaja.

Las reglas de validación dejaron de vivir en el código y pasaron a vivir en el grafo:

(rol_documento, dominio, O)        ∈ M(K, K)
(rol_documento, rango,   K)        ∈ M(K, K)
(rol_documento, etiqueta_en, "Documento") ∈ M(K, K)
# el motor valida el guardado leyendo estas tres tripletas:
# venta (O) escribe documento (K) → coincide con dominio O, rango K → válido

El humano. Queda en pie la tercera frontera, y esta no es del modelo. Es del lector.

Cuando todo es (sujeto, rol, valor), desaparecen las tablas y los formularios con nombre, que son los que normalmente te dicen dónde estás parado.

Toda esa potencia se paga con esfuerzo mental.

El inspector devuelve algo de suelo firme, lo justo para no ahogarse. Pero falta la pieza grande: que las vistas con nombre vivan también dentro del grafo. Que sean datos, y no un accidente de la pantalla.

Sigue pendiente, y reaparece en el inventario de lo que falta.

La interfaz, por detrás de su propia teoría

El experimento reflexivo no fue la última presión.

Vino otra después, de otra clase. En vez de describirse a sí mismo, el modelo tuvo que dejarse operar.

Una IA habló con el grafo por su cuenta, y cargó y consultó los datos de un sistema real en producción, el mismo yaku del capítulo 24. Sin ningún humano en medio que tradujera sus intenciones.

La frontera apareció pronto.

Un cliente estaba registrado dos veces, con dos identificadores distintos, y había que dejar constancia de que era uno solo.

La interfaz ofrecía dos puertas: corregir un dato mal anotado, o fechar un dato que había cambiado. Ninguna servía. No había ni error ni cambio, sino dos nombres para la misma persona.

Obligado a elegir entre las dos puertas que existían, eligió corregir.

No falló nada. La consulta siguiente devolvió una cifra menor que la real, con la misma cara de confianza que si hubiera sido correcta.

Fíjate en qué se parece al tropiezo con instancia_de, y en qué no.

Allí el prototipo iba detrás de su propia teoría: el libro ya clasificaba cosas de cualquier eje y el código no lo dejaba.

Aquí la teoría estaba completa desde mucho antes. mismo_que lleva escrito desde el capítulo 11, con sus tres vías de resolución y su precedente en owl:sameAs. Lo que iba detrás era la interfaz, que sabía nombrar dos de los tres casos y se callaba el tercero.

Un modelo no puede elegir una opción que su interfaz no sabe decir.

La distinción entre los tres casos (el mundo cambió, lo anotamos mal, son la misma cosa) vive ahora en el capítulo 11, que es su sitio. Lo que aporta esta segunda presión es la medida de lo que cuesta dejarla implícita.

Una interfaz que ofrece dos puertas donde el mundo tiene tres no produce un error: produce una respuesta.Sobre la segunda presión

El vértigo de mirarse al espejo

Esta prueba de fuego deja una lección muy humana, y conviene nombrarla, porque es un hallazgo y no un defecto del lector.

Un modelo capaz de describirse a sí mismo marea por construcción. En el límite no hay «tablas» ni «pantallas», solo preguntas sobre preguntas.

¿Qué es un campo? Una clase. ¿Qué es esa clase? Un ejemplar del concepto «campo». ¿Y ese concepto? Otro nodo del grafo, descrito por más tripletas.

La torre no tiene fondo, y al principio desconcierta.

Pero ese mareo no invalida la propuesta. La confirma.

Y de paso explica por qué un modelo así necesita textos, historias y ejemplos con nombre y apellido para que las personas puedan usarlo. Es, en el fondo, la razón de ser de este libro.

El grafo vuelve la información operable para las máquinas. Nuestro lenguaje, nuestros ejemplos y nuestro diseño son lo que la vuelve comprensible para nosotros.

Que un modelo abstracto pueda usar su propia estructura para describir la herramienta que lo gestiona es la evidencia más contundente que el prototipo pudo arrojar.

Vale más que ocho dominios distintos. Es el modelo hablando de sí mismo sin salirse de sus siete ejes: corrigiéndose cuando una regla quedó corta, tragándose como datos lo que otro sistema tendría que escribir en código, y midiendo su ambición en un número limpio.

Cinco hechos, cero líneas.

El grafo no describe el sistema. El grafo es el sistema.

A esa pregunta (la seguridad y la privacidad del grafo compartido) dedicamos el próximo capítulo. Y al inventario de lo pendiente, el siguiente.