Arqueología de un sistema real

Son las 19:40 de un viernes. En la recepción de un complejo que reúne sauna, hostal, gimnasio y cafetín, una empleada teclea en una pantalla que lleva años igual: fondo gris, botones cuadrados, una rejilla de productos con códigos cortos.

El sistema se llama yaku y corre sobre MySQL desde hace una década.

En la última media hora registró una socia que entró a entrenar sin pagar nada. Un huésped que cargó una cerveza a su habitación. Un cliente de paso que pagó veinticinco soles por una sauna. Y una cortesía: una sauna regalada a una clienta que cumple años.

Cuatro hechos del mismo turno, tecleados en segundos, guardados en filas que nadie volverá a mirar de una en una.

yaku no sabe que está modelando agencia, vigencia ni cobertura. Solo registra ventas. Y esa es la tesis del capítulo: debajo de sus nombres de columna ya están enterradas casi todas las coordenadas que este libro lleva veintiún capítulos construyendo.

El capítulo 16 modeló el spa Serena Termas de punta a punta: servicios, comprobantes, impuestos, todo limpio sobre una hoja en blanco. Sirve para entender qué se puede hacer.

Pero el libro no puede quedarse ahí. La pregunta que de verdad se hace la mayoría de sus lectores no es «¿cómo modelaría esto desde cero?». Es otra, mucho más incómoda: «¿cómo aplico WQuestions sin romper lo que ya funciona?».

El lector típico no tiene una pizarra. Tiene un ERP de diez años, un CRM heredado, una base con tres mil tablas o un sistema artesanal en PHP que mueve la empresa desde antes de que él llegara.

yaku es exactamente ese escenario, con la ventaja de que es real, está vivo y podemos mirarle las entrañas.

yaku en media página

yaku corre sobre MySQL y administra, con un solo esquema, cuatro líneas de negocio que comparten recepción: el sauna, el hostal, el gimnasio y el cafetín. Sus tablas centrales son las que cualquier negocio de servicios termina teniendo, llámense como se llamen:

cliente: quiénes consumen. persona: los empleados: recepción, masajistas, instructores. Entre ambas tablas vive todo lo que el modelo llamaría el eje Q, repartido en dos según un criterio puramente operativo (quién cobra y quién paga), no semántico.

producto: todo lo vendible bajo un mismo techo, de habitaciones y sesiones de sauna a jugos, gaseosas y planes mensuales. venta más ventadet: las comandas y sus líneas. asistencia: entrada y salida del gimnasio, con banderas para sauna y ducha. socio más plan: las membresías vigentes.

Y aquí aparece el primer detalle revelador, el que justifica la palabra «arqueología».

El campo producto.MARCA no guarda lo que promete su nombre. No guarda la marca comercial. Guarda la familia de negocio: HOSTAL, SAUNA, GYM, RESTAURANT, STOCK.

Es decir, yaku ya clasifica sus productos en categorías. Ya tiene un eje K funcionando, escondido tras un nombre de columna que disimula su función real.

Excavar yaku es exactamente esto: levantar la capa de nombres engañosos y reconocer debajo las coordenadas que el modelo predice.

Qué de WQuestions ya estaba enterrado en yaku

El mapeo arranca con una pregunta inocente a cada tabla: ¿en qué eje vive su contenido?

La respuesta, puesta sobre los siete ejes, produce el mapa de la figura 24.1. Conviene leerlo despacio: tres de sus observaciones sostienen el capítulo entero.

Primera observación · yaku ya implementa D6 sin saberlo

Los campos socio.desde y socio.hasta son justo el patrón que el capítulo de situaciones prescribe para lo que cambia con el tiempo. La membresía no se guarda como atributo del cliente, sino como un evento con inicio y fin.

Cuando un socio renueva, yaku no sobrescribe el registro anterior. Crea uno nuevo.

Esa decisión, tomada hace años por alguien que seguramente solo quería un historial de pagos, es la vigencia que el modelo formaliza como D6.

Y tiene la consecuencia exacta que D6 promete. «¿Qué socios estaban activos el 15 de marzo del año pasado?» se responde con precisión, sin reconstrucciones aproximadas.

Esto se traduce al modelo sin mover una fila de yaku. La membresía de una socia es un hecho con su rango de validez, y el sistema heredado ya guarda los dos extremos del rango:

Segunda observación · yaku ya tiene un embrión de estatus_factual

Las banderas venta.ANULA y venta.CANCELADO son la versión cruda de algo que el spa modeló con cuidado: el estatus_factual, ese campo en K que distingue {real, intencionado, planeado, hipotético, cancelado}.

yaku cubre sin problemas el extremo negativo, «esto no pasó», con sus dos banderas. Lo que le falta es el otro extremo: el intencionado.

El cliente que estuvo a punto de comprar el plan trimestral y se fue sin firmar deja una huella pobrísima: una nota en prosa dentro de cliente.NOTAS. No consultable, no sumable, invisible para cualquier reporte.

La intención de compra fallida, que es oro puro para marketing, se evapora.

Tercera observación · el eje L está externalizado, pero es recuperable

yaku no tiene tabla de lugares. Las habitaciones del hostal viven como filas de producto, con códigos H103, H201 y demás.

A primera vista parece una carencia. En realidad es una decisión de modelado que el capítulo 16 ya preveía: una misma entidad puede vivir en O y en L a la vez. La cámara de vapor del spa era a la vez una máquina y un lugar.

yaku priorizó la cara O de la habitación, para que entrara sin fricción en el flujo de ventas, y dejó implícita la cara L.

La buena noticia es que WQuestions puede recuperar esa cara sin cambiar yaku. Basta declarar en el lexicon que cada código de habitación es también un individuo del eje L. El dato ya está. Solo le faltaba el segundo sombrero.

Los sistemas heredados se aproximan a WQuestions a pedazos, sin nombrarlo. La arqueología no migra: diagnostica.El método del capítulo

Un concepto nuevo que el ejercicio regala: las modalidades de cobertura

El spa introdujo el estatus_factual para responder a una sola pregunta: ¿esto pasó o no?. Importante, pero de una sola dimensión.

yaku, por ser un negocio real con cuatro líneas conviviendo, saca a la luz otra dimensión que el libro no había formalizado: ¿cómo se cobró este servicio?.

No es lo mismo que «si pasó». Un servicio puede haber ocurrido con total certeza y, aun así, haberse cobrado de cuatro maneras distintas. En yaku conviven las cuatro el mismo viernes:

Las cuatro comparten el mismo hecho («se usó el sauna») y responden distinto a la pregunta del cobro.

En yaku, distinguirlas obliga a cruzar tres señales frágiles: el valor de asistencia.IMPORTE, la presencia de un socio activo y la existencia de una venta asociada. Tres consultas que se rompen en cuanto alguien renombra un producto o cambia una regla de caja.

WQuestions las colapsa en un solo cable del eje M, que llamaremos cubierto_por:

(uso_sauna_001, instancia_de, servicio_sauna)
(uso_sauna_001, cliente,      juan)
(uso_sauna_001, cubierto_por, pago_directo)                # caso 1: paga y sale

(uso_sauna_002, cubierto_por, contrato_plan_maria_2026)    # caso 2: apunta al contrato
(uso_sauna_003, cubierto_por, estancia_carlos_5234)        # caso 3: apunta a la venta-padre
(uso_sauna_004, cubierto_por, promo_cumpleanos_ana)        # caso 4: apunta a la promoción

Cada uso_sauna es, en el fondo, el mismo hecho: alguien usó el sauna. La modalidad de cobertura, aparte, explica por qué no se cobró como pago directo.

Lo elegante es que cubierto_por apunta a entidades de naturaleza distinta (un contrato, una estancia, una promoción) sin que el cable tenga que saber de antemano cuál. El destino lleva su propia clase.

Y sirve mucho más allá de un complejo de sauna. Cualquier club deportivo, hotel o clínica con seguros vive la misma mezcla de orígenes de cobro.

¿Dónde viven los datos? Las tres arquitecturas de convivencia

Decir «vamos a aplicar WQuestions» deja sin responder una pregunta que en la pizarra limpia ni existía: ¿dónde viven los datos?

Cuando ya hay un MySQL en producción con años de ventas, no hay una sola respuesta. Hay tres, y elegir bien evita mucho retrabajo. La figura 24.2 las ordena de menor a mayor compromiso.

Arquitectura A · la vista virtual

El motor no almacena datos propios. Cuando recibe una consulta, su mapper la traduce a SQL contra las tablas heredadas. yaku sigue siendo la única fuente de verdad.

No hay sincronización, no hay copia, no hay retraso. «¿Cuántas saunas tomó Juan este mes?» se convierte por dentro en algo que el MySQL ya sabe responder:

-- El mapper traduce el patrón WQ a SQL contra las tablas vivas de yaku.
-- (uso_sauna, cliente, ?)  +  (uso_sauna, durante, este_mes)
SELECT COUNT(*)
FROM   ventadet d
JOIN   venta    v ON v.id = d.id_venta
JOIN   producto p ON p.id = d.id_producto
WHERE  v.id_cliente = 'juan'
  AND  p.MARCA      = 'SAUNA'
  AND  v.fecha BETWEEN '2026-06-01' AND '2026-06-30'
  AND  v.ANULA = 0;

Funciona de maravilla para lo que el sistema heredado ya sabe contestar: «¿qué huéspedes están alojados ahora?», «¿cuánto facturó el cafetín ayer?».

Y fracasa, por construcción, para todo lo que no modela: la vigencia histórica de la dirección de un cliente, las intenciones de compra fallidas, la justificación de una cortesía.

Si el dato no está en una columna, ningún SQL lo inventa.

Arquitectura B · el grafo paralelo

Una tabla aparte, fact(subject, predicate, object, t_from, t_to), en MySQL, Postgres o donde sea, recibe por un proceso ETL las filas de yaku convertidas en hechos atómicos. El motor consulta solo esa tabla.

Su virtud es la libertad. Todo lo que el sistema heredado no modela (las intenciones, el porqué, la vigencia completa, las modalidades de cobertura) cabe limpio, porque la tabla está diseñada justo para eso.

-- El grafo paralelo: una sola tabla aloja cualquier hecho, incluso los
-- que yaku no sabe representar.
CREATE TABLE fact (
  subject    VARCHAR(64),
  predicate  VARCHAR(64),
  object     VARCHAR(128),
  t_from     DATETIME,
  t_to       DATETIME NULL
);

-- Una intención de compra fallida: imposible de guardar como tal en yaku.
INSERT INTO fact VALUES
  ('intencion_noa_01', 'instancia_de',    'intencion_compra', NULL, NULL),
  ('intencion_noa_01', 'cliente',         'noa',              NULL, NULL),
  ('intencion_noa_01', 'sobre_producto',  'plan_trimestral',  NULL, NULL),
  ('intencion_noa_01', 'estatus_factual', 'intencionado',     NULL, NULL);

Ese proceso ETL es la arqueología hecha código. Lee una fila de yaku y la descompone en las tripletas que el modelo predice.

Una fila de socio, que para yaku es un renglón con columnas, se convierte en cuatro hechos, uno por cada coordenada que escondía:

def proyectar_socio(fila, u):
    """Descompone una fila de la tabla `socio` en hechos atómicos.
    La columna se vuelve cable; el valor, objeto; el eje queda implícito."""
    contrato = u.add_individual(f"contrato_plan_{fila.id}")          # un nodo en O
    u.assert_fact(contrato, "instancia_de", clase_de(fila.nplan))    # K · plan_sauna / gym
    u.assert_fact(contrato, "cliente",      fila.id_socio)           # Q · el cable hacia quién
    u.assert_fact(contrato, "desde",        fila.desde)              # T · vigencia (D6)…
    u.assert_fact(contrato, "hasta",        fila.hasta)              # T · …con inicio y fin
    return contrato

Fíjate en lo que ocurre. El nombre de la columna se vuelve el cable. El valor se vuelve el objeto. Y el eje lo decide el lexicon.

La fila plana de yaku, leída así, revela las coordenadas que siempre tuvo. Eso es, en una función, todo el capítulo.

Su límite es el retraso. Entre que una venta entra a yaku y aparece en el grafo pasa un rato.

Para muchos usos da igual: consultas analíticas, campañas de marketing, tableros que se miran una vez al día. Para otros es un bloqueo total, como una decisión que se toma en la caja, frente al cliente, ahora mismo.

Arquitectura C · el híbrido pragmático

Los datos del día a día (clientes, productos, ventas, asistencias) se consultan en vivo contra el sistema heredado, por la vía A. Lo que WQuestions añade (intenciones, modalidades de cobertura, justificaciones, vigencias históricas) vive en la tabla fact paralela, por la vía B. El motor decide adónde ir según el predicado.

Es la que recomendaría para casi cualquier adoptante real. Aprovecha el sistema existente para lo que ya hace bien y le añade encima, sin tocarlo, la capa semántica.

Cero riesgo sobre la operación diaria. Ganancia en cada consulta nueva.

El costo real de construir un lexicon

El capítulo 14 presentó el lexicon como pieza ya construida, y el 31 reconoce que falta poblarlo a nivel idioma: miles de verbos del español, los recursos de FrameNet(14), AnCora.

Pero entre el verbo genérico de un idioma y la entrada usable en producción hay un trabajo intermedio que el libro no había puesto sobre la mesa: construir el lexicon de un negocio concreto.

Para yaku, ese trabajo se reparte en cinco tareas. Ninguna es programación.

La inversión total para yaku es de dos a cinco días de trabajo de campo, clasificación y escritura del lexicon. Es labor de arqueólogo y de lingüista, no de ingeniero.

Y se hace una sola vez. Desde ahí, toda consulta futura sobre el negocio reúsa el mismo lexicon. Un costo fijo y pequeño contra un beneficio que se cobra en cada pregunta de los años siguientes.

El gap del gimnasio · el modelo no inventa información

Toca ahora la observación de fondo, una que la euforia de los ejercicios de pizarra limpia tiende a callar: el modelo no es alquimia. Si un dato no se captura en ningún lado, no aparece en el grafo por arte de magia.

En yaku, el uso del gimnasio solo se registra cuando el cliente es socio en plan. Entra al sistema por la tabla asistencia.

Los días sueltos comprados como producto MARCA=GYM se cobran en venta, pero no dejan registro de entrada y salida. No existe una tabla asistencia_walkin_gym.

Así que «¿cuántas horas usó alguien el gimnasio este mes?» hoy no se puede responder para los clientes de paso. Ni con yaku puro, ni con WQuestions encima.

Una consulta real, de punta a punta, sobre yaku

Cerremos con un ejercicio concreto que ata todo lo anterior. La recepcionista pregunta: «¿qué huéspedes han usado sauna durante su estancia este mes, y cuánto extra han generado?».

Esa consulta no tiene vista preparada en yaku. Hoy obliga a cruzar asistencia con venta (filtrada por MARCA=HOSTAL) y con ventadet (filtrada por MARCA=SAUNA o por la bandera asistencia.Sauna). Y aún hay que separar las saunas anexas del gimnasio de las saunas de paso.

Es posible, pero frágil: un cambio en los nombres de productos rompe el reporte. Así de enredado se ve en SQL crudo:

-- Hoy, en yaku puro: frágil y atado a los nombres de los productos.
SELECT  h.id_cliente, SUM(d.importe) AS extra
FROM    venta h
JOIN    producto ph ON ph.id = h.id_producto AND ph.MARCA = 'HOSTAL'
JOIN    venta v     ON v.id_cliente = h.id_cliente
JOIN    ventadet d  ON d.id_venta   = v.id
JOIN    producto ps ON ps.id = d.id_producto AND ps.MARCA = 'SAUNA'
WHERE   v.fecha BETWEEN h.fecha AND h.fecha_checkout
  AND   v.fecha >= '2026-06-01'
  AND   v.ANULA = 0
GROUP BY h.id_cliente;

En WQuestions (en la arquitectura híbrida C, contra el propio yaku) la misma pregunta se vuelve una composición de roles canónicos, legible y estable:

filter(O,
  instancia_de        = uso_sauna,
  durante.instancia_de = estancia_hostal,
  durante.fin         >= inicio_mes,
  cubierto_por.tipo   = pago_directo
)
GROUP BY durante.huesped
PROJECT  SUM(importe)

El motor traduce el patrón al SQL que toque. El modelo de lenguaje, si lo hay, traduce la frase en español a este patrón.

Pero el patrón es la pieza estable: tres roles canónicos (instancia_de, durante, cubierto_por) que cualquier negocio de servicios va a reutilizar tal cual.

Y aquí está la prueba de fuego. La pregunta siguiente («¿alguno de esos huéspedes era además socio del gimnasio?») se contesta añadiendo un filtro: huesped IN socios_activos_gym(inicio_mes, fin_mes).

Sin código nuevo. Sin reporte nuevo. El lexicon ya enseñó qué es un socio del gimnasio, el grafo ya conecta los huéspedes con sus contratos, y la consulta compuesta sale de combinar piezas que ya existen.

La promesa sobre un sistema en producción: convertir cada consulta nueva en una composición de piezas pre-construidas, en vez de un reporte ad hoc más.El retorno de la arqueología

El antes y el después · del cruce frágil a la composición estable

Antes (yaku puro). Cada pregunta que el negocio no había anticipado se convierte en un reporte nuevo, escrito a mano, que cruza tablas por convenciones de nombres (MARCA='SAUNA', banderas booleanas, fechas comparadas a ojo).

Y que se rompe en silencio el día en que alguien renombra un producto o cambia una regla de caja.

El conocimiento del negocio vive en la cabeza de quien escribió cada consulta, y se va con esa persona. La intención fallida, la cortesía y la vigencia histórica, sencillamente, no caben.

Después (WQuestions, híbrido C). Las mismas preguntas se contestan combinando conceptos. El lexicon, construido una sola vez en dos a cinco días, enseña el dialecto del negocio. El grafo conecta los hechos por sus cables. Cada consulta nueva es una combinación de roles que ya existen.

Lo que yaku no modelaba (el intencionado, el cubierto_por, la vigencia completa) vive en la tabla fact paralela, sin tocar una sola fila del sistema.

Y nada de esto exigió migrar yaku. El MySQL sigue corriendo igual que el viernes con el que abrimos.

Del viernes en recepción al consolidado del negocio

Mapear yaku no era el objetivo. Era la condición para poder preguntar.

Y lo que el dueño quiere preguntar no es por la sauna de las 19:40. Es por el negocio entero. Cuánto factura cada línea (sauna, hostal, gimnasio, cafetín), cuál crece y cuál se estanca, qué día de la semana llena el local.

Antes esas respuestas vivían repartidas entre venta, ventadet y los valores de producto.MARCA, cruzados a mano cada vez. Ahora son cortes de un mismo grafo, uno por familia de servicio.

# Facturación del sauna — un corte; el consolidado recorre las cuatro familias
suma(u, "importe", Pattern(fixed={"familia": u.ind("sauna")},
                           type_constraint=u.ind("venta")))

Qué quedó probado

La arqueología de yaku deja tres lecciones que ningún dominio de pizarra limpia podía dejar, y que valen para cualquier sistema heredado, no solo para un complejo de sauna.

Y queda un cuarto saldo, distinto de los otros tres porque es una ganancia y no una lección. El ejercicio regaló un concepto nuevo: las modalidades de cobertura (cubierto_por), perpendiculares al estatus_factual y útiles en cualquier negocio donde un servicio admita orígenes de cobro distintos.

Un sistema real, por el solo hecho de ser real, empujó al modelo a un lugar donde la pizarra limpia nunca lo habría llevado.

En suma: la arquitectura no movió una línea entre los ocho dominios diseñados desde cero y este sistema heredado. Lo único que cambió fue el lexicon, la topología de persistencia y un cable nuevo en la familia del porqué.

Tres caminos de salida y la conexión con lo que sigue

El capítulo 16 demostró que el modelo absorbe un negocio diseñado desde cero. Este demostró que el modelo se aplica sobre un negocio ya digitalizado, sin migrar nada. El lector que llega hasta aquí puede tomar uno de tres caminos, según cuánto quiera arriesgar:

Solo ver si vale la pena. Aplicar la arqueología semántica a sus propias tablas: tabla por tabla, ¿a qué eje responde? Es trabajo de un fin de semana y devuelve un diagnóstico claro de cuánto del modelo ya está implementado y cuánto falta.

Probar el modelo de verdad. Montar la arquitectura híbrida C y un único POC de una consulta crítica, de punta a punta. Si esa consulta sobrevive, el resto es repetir el patrón sobre todas las demás.

Ir más lejos. El capítulo 26 da el paso siguiente. El lexicon que construimos aquí se vuelve el esquema de funciones que un modelo de lenguaje consume. Y entonces el personal de yaku puede preguntar en español llano, sin saber que debajo hay un grafo.

El yaku que dio origen a este capítulo sigue funcionando como siempre. Ninguna fila se movió de lugar.

Lo que cambió es que ahora, con dos a cinco días de inversión en el lexicon, cualquier consulta del negocio se responde combinando conceptos en vez de programando reportes.

Esa diferencia, multiplicada por años de operación, es lo que justifica el esfuerzo. Y es la prueba más terrenal de que WQuestions no exige empezar de nuevo: exige, apenas, aprender a leer lo que ya estaba escrito.

Con eso cerramos los dominios reales. El próximo capítulo cambia de registro y somete al modelo a cuatro mundos de otra naturaleza (música, química, fútbol y contratos) buscando, esta vez a propósito, dónde se resiste.