Arqueología de un sistema real

Son las 19:40 de un viernes. En la recepción de un pequeño complejo que reúne un sauna, un hostal, un gimnasio y un 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 ha registrado 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, cada uno tecleado en segundos, cada uno guardado en filas que nadie volverá a mirar individualmente. yaku no sabe que está modelando agencia, vigencia ni cobertura. Solo registra ventas. Y, sin embargo (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. Es un ejercicio valioso para entender qué se puede hacer. Pero el libro no puede quedarse ahí, porque la pregunta operativa de la mayoría de sus lectores no es «¿cómo modelaría esto desde cero?», sino 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 relacional 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:

Y aquí aparece el primer detalle revelador, el que justifica la palabra «arqueología». El campo producto.MARCA no guarda lo que su nombre promete (la marca comercial del producto). Guarda su familia de negocio: HOSTAL, SAUNA, GYM, RESTAURANT, STOCK. Es decir, yaku ya clasifica sus productos en categorías (ya tiene un eje K en funcionamiento) solo que escondido tras un nombre de columna que disimula su función real. Excavar yaku es, literalmente, 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 que se le hace 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, porque 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, exactamente, el patrón que el capítulo de situaciones prescribe para los hechos que cambian con el tiempo: la membresía no se guarda como un 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 probablemente solo quería un historial de pagos) es la vigencia bitemporal que el modelo formaliza como D6. Y tiene la consecuencia exacta que D6 promete: la pregunta «¿qué socios estaban activos el 15 de marzo del año pasado?» se responde con precisión, sin reconstrucciones aproximadas ni «depende de qué tabla mires».

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 del capítulo 16 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 flags. Lo que le falta es el extremo opuesto: el intencionado. El cliente que estuvo a punto de comprar el plan trimestral y se fue sin firmar deja, en yaku, una huella pobrísima: una nota en prosa libre dentro de cliente.NOTAS, no consultable, no agregable, invisible para cualquier reporte. La intención de compra fallida (oro puro para marketing) se evapora.

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

yaku no tiene tabla de lugares físicos. Las habitaciones del hostal viven como filas de producto (códigos H103, H201, etcétera). 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, simultáneamente, una máquina (objeto) y un lugar. yaku eligió priorizar 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: WQuestions puede recuperar esa cara sin cambiar yaku. Basta declarar, en el lexicon, que cada código de habitación es además 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 pregunta única: ¿esto pasó o no?. Es una distinción importante, pero unidimensional. yaku, por ser un negocio real con cuatro líneas conviviendo, hace aflorar otra dimensión ortogonal que el libro no había formalizado hasta aquí: ¿cómo se cobró (o se cubrió) 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 la operación diaria de yaku conviven, el mismo viernes, las cuatro:

Las cuatro modalidades comparten el mismo hecho factual («se usó el sauna») pero responden de forma distinta 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 único cable explícito 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 su esencia, un hecho idéntico: alguien usó el sauna. La modalidad de cobertura, por separado, explica por qué no se cobró como pago directo. Lo elegante del diseño 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 es generalizable mucho más allá de un complejo de sauna: cualquier club deportivo, hotel o clínica con cobertura de seguros vive la misma heterogeneidad 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 crítica que en la pizarra limpia ni siquiera 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 WQuestions 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 latencia. Una pregunta del estilo «¿cuántas saunas tomó Juan este mes?» se convierte, internamente, 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 las preguntas que el sistema heredado ya sabe contestar con sus tablas actuales («¿qué huéspedes están alojados ahora?», «¿cuánto facturó el cafetín ayer?»). Y fracasa, por construcción, para todo lo que el legacy 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 separada —fact(subject, predicate, object, t_from, t_to), en MySQL, Postgres, SQLite o donde sea— recibe, vía un proceso ETL o de captura de cambios, una proyección de las filas de yaku convertidas en hechos atómicos. El motor consulta exclusivamente esta tabla fact. Su virtud es la libertad: todo lo que el legacy no modela (las intenciones, el porqué, la vigencia bitemporal completa, las modalidades de cobertura) cabe limpio, porque la tabla está diseñada justo para alojarlo.

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

El proceso ETL que alimenta esa tabla es, en esencia, la arqueología hecha código: lee una fila relacional 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 atómicos, uno por cada coordenada que esa fila 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

Repara en lo que ocurre: el nombre de la columna se vuelve el cable, el valor se vuelve el objeto, y el eje queda determinado por 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 la latencia. Entre que una venta entra a yaku y aparece en el grafo hay un retraso. Para muchas aplicaciones eso es irrelevante (consultas analíticas, campañas de marketing, tableros que se miran una vez al día); para otras es un bloqueador insalvable (una decisión que se toma en la caja, frente al cliente, ahora mismo).

Arquitectura C · el híbrido pragmático

Los datos transaccionales (clientes, productos, ventas, asistencias) se consultan en vivo contra el legacy, vía A. Los datos puramente semánticos que WQuestions agrega (intenciones, modalidades de cobertura, justificaciones, vigencias históricas) viven en la tabla fact paralela, vía B. El motor decide a qué backend ir según el predicado de la consulta. Es la que recomendaría para casi cualquier adoptante real: aprovecha el sistema operativo existente para lo que ya hace bien y le añade encima, sin tocarlo, la capa semántica que el modelo aporta. Cero riesgo sobre la operación diaria, ganancia incremental en cada consulta nueva.

El costo real de construir un lexicon

El capítulo 14 presentó el lexicon como una pieza ya construida. El capítulo 30 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 desglosa en cinco tareas, y ninguna de ellas es programación.

La inversión total para yaku es del orden de dos a cinco días de trabajo etnográfico, clasificación y escritura del lexicon. Es labor arqueológico-lingüística, no ingeniería. Y se hace una sola vez: desde ese punto, toda consulta futura sobre el negocio reúsa el mismo lexicon. Esa amortización es el retorno que justifica el esfuerzo inicial: 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 generan registro de entrada y salida: no existe una tabla asistencia_walkin_gym. Por tanto, la pregunta «¿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 una 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 desambiguar las saunas anexas del gimnasio de las saunas de paso. Es factible, 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 apropiado; el modelo de lenguaje, si lo hay, traduce la frase en español a este patrón. Pero el patrón mismo 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 de seguimiento («¿alguno de esos huéspedes era además socio del gimnasio?») se contesta agregando un solo 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; 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 pierde cuando esa persona se va. La intención fallida, la cortesía, la vigencia histórica, sencillamente no caben.

Después (WQuestions, híbrido C). Las mismas preguntas se contestan componiendo 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 canónicos; cada consulta nueva es una combinación de roles que ya existen. Lo que yaku no modelaba (el intencionado, el cubierto_por, la vigencia bitemporal completa) vive en la tabla fact paralela sin tocar una sola fila del sistema operativo. Y nada de esto requirió migrar yaku: el MySQL sigue corriendo exactamente igual que el viernes con el que abrimos.

Del viernes en recepción al consolidado del negocio

Mapear yaku no fue el objetivo final: fue la condición para poder preguntar. Y lo que el dueño quiere preguntar no es por la sauna de paso de las 19:40, sino 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 de ventas, 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 tres anteriores porque es una ganancia y no una lección: el ejercicio regaló un concepto nuevo, las modalidades de cobertura (cubierto_por), ortogonal al estatus_factual y reutilizable en cualquier negocio donde un servicio admita orígenes de cobro heterogéneos. 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 conceptual 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:

El sistema 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 puede responder componiendo 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 cualitativamente distintos (música, química, fútbol y contratos) buscando, esta vez a propósito, dónde se resiste.