La prueba reflexiva

Imagina una pantalla partida en dos. A la izquierda, una aplicación de gestión cualquiera: un menú lateral, un formulario de venta con sus campos, una grilla con los últimos registros. Nada que un programador no haya construido cien veces. A la derecha, en un panel angosto, una lista que crece a cada clic: ventaO tiene_campo campo_venta_montoO, y debajo otra, y otra. Ese panel no describe la aplicación: es la aplicación. Cada opción del menú, cada campo del formulario, cada columna de la grilla que ves a la izquierda existe porque a la derecha hay una tripleta que lo afirma. Lo que estás mirando es un programa hecho enteramente de hechos WQuestions, y a su lado, los hechos que lo sostienen.

A lo largo de este libro hemos apretado WQuestions desde muchos ángulos. Lo apretó el lenguaje, con sus nominalizaciones y sus modismos, en el capítulo 15. Lo apretaron ocho dominios que no se parecen en nada, del spa a la operación minera. Lo apretó un sistema de verdad, en producción, cuando hicimos arqueología del yaku. Y lo apretaron, a propósito, cuatro dominios incómodos elegidos para que crujiera. Todas esas presiones tienen algo en común: vienen de fuera. El modelo describe un mundo (ventas, pacientes, partidos, contratos) y la pregunta es si el mundo cabe en sus siete ejes.

Queda una presión más, y es la más exigente de todas: pedirle al modelo que se describa a sí mismo. No modelar un dominio externo, sino construir una herramienta (un programa con menús, formularios, tipos de dato y reglas de comportamiento) cuya estructura, cuyos tipos y cuya conducta sean, ellos mismos, hechos WQuestions. Si la tesis del libro es cierta, si las preguntas son la base universal de la información, entonces la propia maquinaria que manipula información tendría que poder expresarse en esas preguntas. Este capítulo cuenta qué pasó cuando lo intentamos. No venimos a presumir de una varita mágica; venimos, como en el capítulo 15, con honradez: a mostrar qué aguantó, qué se dobló para aguantarlo y qué quedó al descubierto.

Una aplicación hecha de preguntas

Construimos, sobre el prototipo, una pequeña aplicación de gestión: 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 decisivo no es la aplicación; es de qué está hecha. Cada opción del menú, cada campo de cada formulario, cada tipo de dato, cada relación entre entidades y cada acción que el programa ejecuta es una tripleta (sujeto, rol, valor) en un único grafo.

El menú es un objeto reificado que tiene_opcion a otros objetos; cada opción tiene_accion una acción; cada acción es instancia_de un verbo (mostrar_texto, abrir_formulario, abrir_grilla, guardar) que un evaluador genérico interpreta. El esquema de una entidad también es dato: la entidad tiene_campo a descriptores que declaran su etiqueta, su tipo_dato y su orden. Un registro es un individuo instancia_de su tipo, con un hecho por campo. No hay, en ninguna parte, una tabla venta con columnas fijas ni una clase Formulario con atributos cableados. Hay hechos, y un motor que los lee.

(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)

La consecuencia se ve en la pantalla del propio programa, en ese panel de la derecha que abrió el capítulo: al lado de cada vista, un inspector muestra las tripletas que la sostienen. Lo que ves es, literalmente, lo que hay en el grafo. La interfaz no es una capa que traduce una base de datos a botones; es una proyección directa de los hechos.

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 se puede resumir en una sola operación. Si la estructura y el comportamiento son de verdad datos, entonces agregar estructura debería costar insertar hechos, no escribir código. Esa es la prueba reina: ¿cuánto cuesta agregar un campo nuevo a una entidad que ya existe?

Lo medimos en vivo, con el sistema corriendo, agregando el campo «Documento» a la entidad venta. Estas son las tripletas que insertamos, 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. Ninguna línea de código en el motor, en el servidor ni en la interfaz. Al recargar, el formulario dibujó el campo, la grilla le sumó la columna y el guardado lo persistió, porque las tres operaciones leen el esquema del grafo en lugar de conocerlo de antemano. Ese número (cinco hechos, cero código) es el resultado central 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 abstracto. Las tres aguantaron en concreto.

El comportamiento también es dato

Una y otra vez, a lo largo del libro, apareció la figura del evaluador externo: el motor que recorre el grafo y ejecuta lo que los hechos prescriben, separado del grafo, que solo almacena. Aquí ese evaluador dejó de ser una promesa y pasó a ser código que corre: un despachador genérico que, dado un verbo (un tipo del eje K), ejecuta la conducta asociada.

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ó esencialmente datos, no 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, incapaz de hablar con el de al lado. El antídoto del libro es un único piso de hechos donde las entidades se reúsan. Lo comprobamos modelando «cliente» y «proveedor» no como tipos distintos, sino como roles contextuales: el nombre del campo en la venta o en la 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 solo individuo, dos papeles según el contexto. El anti-Babel no fue una aspiración que hubo que forzar; cayó solo en cuanto dejamos de modelar el rol como un tipo.

La vigencia es la forma natural del «editar»

La edición de un dato se implementó sin borrar nada: editar un valor es asentar un hecho nuevo y leer el más reciente. Es bitemporalidad en miniatura (la vigencia de la decisión D6): historial gratis, ninguna sobreescritura destructiva. Y resultó ser la forma natural de implementar el «update» de un CRUD, no un agregado teórico que hubo que justificar.

La auto-corrección: instancia_de pasa a V→K

El experimento no solo validó: forzó una corrección del prototipo, y vale la pena contarla, porque es el método del libro operando sobre sí mismo. Para clasificar a una persona (decir «Ana es un cliente») hace falta el hecho (ana, instancia_de, cliente). Pero ana vive en el eje Q, es un agente, y el prototipo había restringido instancia_de a sujetos del eje O. La carga reveló la contradicción de inmediato.

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 supuso que clasificar es una operación universal. El prototipo estaba, sencillamente, detrás de su propia teoría. La corrección fue generalizar instancia_de de O→K a V→K, donde V es un comodín que significa «cualquier eje de valor».

Ese comodín no resuelve solo este caso. Es exactamente el mecanismo que el capítulo 30 reclama para relajar otras signaturas demasiado estrechas (pensemos en 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.

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 quedó señalada como trabajo pendiente.

El catálogo canónico es invisible para el usuario final (es el lexicon su interfaz, como fija la decisión D8), pero la carga reflexiva lo obligó a abarcar también lo que el usuario crea sobre la marcha. El tipado dejó de vivir en Python y pasó 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 no es del modelo, sino del lector. Cuando todo es (sujeto, rol, valor), se pierde el andamiaje de tablas y formularios con nombre que normalmente carga el significado. El poder de la abstracción reflexiva tiene un peaje cognitivo. El inspector («lo que ves es lo que hay») re-concreta lo suficiente para no ahogarse, pero la pieza que falta es hacer de las vistas y proyecciones con nombre ciudadanas del grafo: datos, no accidente de la interfaz. Es trabajo pendiente, y reaparece como tal en el capítulo que sigue.

Honradez intelectual

Conviene nombrar el vértigo, porque es un hallazgo y no un defecto del lector. Un modelo capaz de describirse a sí mismo es, por construcción, mareante: en el límite no hay «tablas» ni «pantallas», solo preguntas sobre preguntas. ¿Qué es un campo? Una clase. ¿Qué es esa clase? Una instancia del concepto «campo». ¿Y ese concepto? Otro nodo del grafo, descrito por más tripletas. La torre no tiene fondo, y al principio eso desconcierta.

Pero ese mareo no invalida la propuesta; la confirma. Y, al mismo tiempo, explica por qué un modelo así necesita prosa, ejemplos y una capa de re-concreción para que las personas puedan usarlo. Es, en el fondo, la razón de ser de este libro: el grafo es operable; el texto es lo que lo vuelve comprensible.

Que el modelo pueda describir su propia herramienta es la evidencia más fuerte que el prototipo produjo. Más que ocho dominios distintos, es el modelo hablando de sí mismo sin salirse de sus siete ejes: corrigiéndose cuando una signatura quedó corta, absorbiendo como datos lo que un sistema convencional cablearía en código, y midiendo su propia ambición en un número limpio (cinco hechos, cero líneas).

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.