El viernes de marzo — la llamada de la sede costera
Volvamos al viernes que cerró el último Pulse.
Una sede pequeña de Objectville en una ciudad costera del norte. Dieciocho mesas, dos cocineros, una gerente con voz contenida que llama a la central a las nueve de la mañana. Hace seis semanas firmó la entrada de un lote de Pecorino Romano DOP — el queso que va a la pizza estrella de la carta, la que aparece en los menús de todas las sedes con la denominación de origen escrita en grande. Acaba de llegarle un comunicado del proveedor: el laboratorio que emite las certificaciones envió mal el documento a finales de enero. Lo que se etiquetó como Pecorino Romano DOP era pecorino de pasto — sin denominación de origen. Y ese lote — el lote MZ-2026-PRO-014 — entró por la puerta el 2 de febrero, pasó las validaciones de su día, viajó por la cadena y se distribuyó a varias sedes durante seis semanas.
Hasta dónde se ha esparcido el error nadie lo sabe en el momento de la llamada.
La semana pasada el chef del Mediterráneo nos hizo refinar una regla — V1 a V2, hacia adelante. Hoy la gerente costera nos pide algo distinto: no refinar — eso es para mañana —, sino reconstruir el pasado bajo la regla de aquel momento, sabiendo lo que sabemos hoy. Son dos preguntas que el mismo aparato tiene que sostener, en dos días distintos, para dos sedes distintas. La primera la cubrió el robot validador. La segunda la cubre lo que voy a contar hoy.
Y aquí empiezan los problemas serios.
Primero — ¿qué pizzas se sirvieron con ese lote?. No es una pregunta filosófica. Es una pregunta operativa: cuántas, en qué sedes, durante qué ventana, a qué clientes. La respuesta tiene que estar lista antes del lunes, porque la asociación del sector de denominaciones de origen puede pedir trazabilidad documentada del lote — el sello DOP no es marketing, es una protección legal del producto del campo, y servir un queso que no es DOP con etiqueta DOP es responsabilidad civil. Si la cadena no puede reconstruir lo que sirvió, la cadena tiene un problema mayor que el queso.
Segundo — ¿la regla de validación que dejó pasar el queso el 2 de febrero estaba bien o estaba mal?. La regla decía algo del tipo “si el lote viene con certificado DOP firmado por un laboratorio acreditado, y el sello visual coincide con el formato oficial, entra como DOP”. Esa regla pasó el lote MZ-2026-PRO-014 el 2 de febrero. Entonces era una regla correcta — no había información para rechazarlo. Hoy la información ha cambiado: sabemos que aquel certificado era erróneo. ¿Reprocesamos con la regla de hoy o con la regla del 2 de febrero?. Las dos preguntas tienen respuestas distintas, y la respuesta correcta importa.
Tercero — y este es el que hunde a la mayoría de las cadenas — ¿podemos demostrarlo todo sin destruir nada de lo que ya está en el modelo?. Porque cuando un auditor independiente llegue dentro de seis meses pidiendo “reconstrúyeme el menú servido en la sede Costa Norte el 14 de marzo, contra la información que la central tenía ese mismo 14 de marzo”, la respuesta no puede ser “hoy lo tenemos como NO DOP, así que aquel día también lo era”. Aquel día era DOP — el modelo lo decía y la cadena actuó en consecuencia. Hoy no lo es. Las dos cosas son ciertas, y la fábrica tiene que sostener las dos a la vez.
La conversación con la gerente de la sede costera dura cuatro minutos y termina con la frase que cualquier responsable de operaciones reconoce de inmediato:
— “Necesitamos saber hasta dónde, en cuántas, a quién — antes del lunes.”
La pregunta es: ¿se puede?
La respuesta es sí — exacta y sin destruir nada — y vive en cómo está construida la fábrica por dentro. Hoy entro a contestar las dos primeras preguntas — la mecánica del modelo que sostiene esa propiedad. Las dos doctrinas que salen de esa mecánica — reproducir, no recalcular + el caso completo del lote esparcido en cinco sedes con su consulta del lunes — cierran la semana que viene.
Eje 1 — La fábrica que nunca borra: Insert-Only + Audit-Only-Never-Delete
Hay una decisión arquitectónica que toman las cadenas que sobreviven la primera auditoría seria, y que las cadenas que no la toman pagan caro. La decisión es esta: en la fábrica no se borra nada y no se sobrescribe nada. Nunca. Bajo ninguna circunstancia operativa normal.
Cuando una pieza de información del lote MZ-2026-PRO-014 cambia — porque el laboratorio del proveedor corrige una certificación errónea, porque una sede actualiza el peso del queso al recibirlo, porque cambia el campo del proveedor en el contrato — no se sobrescribe la fila antigua. Se inserta una fila nueva con la información actualizada y un sello temporal preciso. La fila antigua queda exactamente donde estaba, con su sello temporal original, como huella de qué decía el modelo en aquel momento.
Esto tiene dos nombres técnicos en el campo del dato y los dos vienen del trabajo de Dan Linstedt — autor canónico de Data Vault 2.0, el modelo subyacente de la fábrica de la cadena (lo presentamos como aparato técnico la semana del almacén central).
El primer nombre es Insert-Only. Significa exactamente lo que dice — solo se insertan filas, nunca se actualizan filas existentes. La operación UPDATE queda fuera del repertorio normal de la cadena en el lado del aparato. Cuando una sede o un proveedor reporta un cambio, el cambio entra como inserción nueva. La consecuencia inmediata es que el aparato no tiene un “estado actual” y un “estado pasado borrado” — tiene una secuencia ordenada de filas que cubren toda la historia, donde cada fila tiene su ventana temporal de vigencia y la última de la cadena es la que está vigente hoy.
El segundo nombre es Audit-Only-Never-Delete. Es el corolario operativo del primero: no se borra. Nunca. La operación DELETE también queda fuera del repertorio normal. Cuando un dato deja de ser relevante, se cierra su ventana temporal — pero la fila no se quita del modelo. La huella queda. Cuando un dato es corregido, no se sustituye — se inserta la corrección y la versión incorrecta queda visible en su ventana original. Cuando un cliente ejerce un derecho al olvido (que vendrá en el bloque regulatorio), el ejercicio del derecho se ejerce dejando huella verificable de que se ejerció, no destruyendo la huella de que el dato existió. Las dos cosas son distintas.
¿Por qué es tan importante esta decisión que casi parece dogmática? Porque cuando un viernes de marzo llega una llamada como la de la sede costera, lo único que separa una respuesta operativa antes del lunes de un proyecto interno de cinco semanas es exactamente esta propiedad.
Si el aparato sobrescribe — y los aparatos tradicionales sobrescriben por defecto, porque el modelo dimensional tipo Kimball y la mayoría de implementaciones operativas lo permiten — entonces cuando hoy se actualice el certificado del lote MZ-2026-PRO-014 de DOP a NO DOP, la fila antigua desaparece. Hoy el modelo sabe que el lote no es DOP. Pero el modelo ha perdido la información de que durante seis semanas creyó que sí lo era. Eso significa que cuando la sede costera pregunte “¿qué pizzas servimos con ese lote en esa ventana?”, el modelo no puede decir nada sobre la ventana — solo sobre el presente. La trazabilidad del error esparcido se ha evaporado con la sobrescritura. Para reconstruirla hace falta volver a logs operacionales, ficheros de respaldo, copias mensuales en frío. Eso es un proyecto, no una consulta.
Si el aparato es Insert-Only y Audit-Only-Never-Delete — y la fábrica lo es por construcción — entonces la fila antigua del lote MZ-2026-PRO-014 sigue donde estaba. Con su VALID_FROM del 2 de febrero, su certificado DOP, y una nueva VALID_TO que ahora marca el 18 de marzo (el día en que el laboratorio mandó la corrección). Justo después, en la misma estructura, otra fila del mismo lote, con VALID_FROM del 18 de marzo, certificado NO DOP, y VALID_TO abierta. Las dos filas conviven. El modelo sostiene las dos verdades simultáneamente, separadas por una ventana temporal precisa. Y ahora la pregunta de la sede costera tiene respuesta operativa — exacta, reconstruida, demostrable — sin abrir un proyecto.
Y aquí cierra un bucle abierto la semana pasada. El catálogo de reglas del robot validador — la documentación viva — funciona por la misma propiedad. Cuando el chef del Mediterráneo forzó la V2 de la regla del Tomate San Marzano DOP a las 19:47 del 18 de marzo, la V1 no se borró. Quedó cerrada con su VALID_TO. La V2 entró con su VALID_FROM. Las dos versiones de la regla conviven en el catálogo, separadas por una ventana temporal precisa. Por eso la pregunta “¿qué regla estaba viva el 14 de marzo?” tiene respuesta operativa.
Las reglas son datos. Los datos viven en estructuras del aparato. El aparato es Insert-Only por construcción. La memoria de la fábrica no es solo la memoria de los lotes — es también la memoria de las reglas con las que validamos cada lote. Misma estructura, misma propiedad, mismo aparato. Eso es lo que hace que la frase “reproducir el pasado contra la regla del momento” tenga sentido operativo y no solo retórico — y eso es lo que aterrizamos íntegro la semana que viene.
Esa es la primera capa de la memoria de la fábrica. La segunda capa la pone el detalle del versionado.
Eje 2 — Cómo versiona la fábrica un cambio: HASH_DIFF, ventanas temporales y el orden de las versiones
Cuando una fila de información cambia en el aparato, la fábrica tiene que responder a tres preguntas concretas, sin trabajo extra, automáticamente, en el mismo paso de inserción:
¿Es realmente un cambio o es la misma información que ya teníamos?
¿Cuál es la versión nueva y cuál la vieja?
¿Cuándo dejó de ser válida la anterior y cuándo empezó a ser válida la nueva?
Las tres preguntas las resuelven tres mecanismos que viven dentro de cada Satellite — la pieza del aparato que registra la información variable de cada cosa con identidad (ver Semana 7) — desde el origen del modelo.
La huella del cambio (HASH_DIFF) responde a la primera. Cada fila que llega al aparato lleva consigo un código corto: una huella digital de su contenido. Si la huella de la fila nueva coincide con la de la fila más reciente del mismo lote, no ha cambiado nada y no se inserta nada. Si no coincide, es una versión nueva y entra. Sin comparar campo a campo. Sin coordinación. Una comparación de huella.
El orden de versiones (COD_VERSION en este ejemplo) responde a la segunda. Cada versión nueva del mismo lote lleva un número secuencial propio: la primera fila del MZ-2026-PRO-014 es la versión 1; la corrección del laboratorio del 18 de marzo abre la versión 2. Cada lote lleva su propia cuenta, independiente del resto. El nombre exacto de ese contador depende del equipo y del motor — timestamps, particiones, punteros de efectividad —; aquí uso COD_VERSION porque es la forma más legible de leer el desglose del ejemplo.
Las ventanas temporales (VALID_FROM y VALID_TO) responden a la tercera. Cada fila del Satellite lleva dos sellos: desde cuándo es válida y hasta cuándo lo era. La fila vigente tiene la VALID_TO abierta — convencionalmente 31-dic-9999, sigue siendo verdad hasta que alguien inserte algo nuevo. Cuando entra una versión nueva, la fila vieja no se toca en su contenido — queda exactamente donde estaba, como huella del pasado — pero su VALID_TO se cierra. El final de una versión marca el inicio de la siguiente, manteniendo la línea temporal continua, sin dejar huecos ni crear solapamientos.
Tres mecanismos, una sola propiedad: la huella detecta si algo cambió, el orden dice en qué secuencia, las ventanas dicen cuándo era verdad. Juntos resuelven las tres preguntas que la gerente costera puso encima de la mesa el viernes. El lote MZ-2026-PRO-014 el lunes siguiente queda así en el aparato — sin sintaxis técnica, solo la lectura humana:
COD_VERSION = 1—VALID_FROM02-feb-2026 09:14:08 ·VALID_TO18-mar-2026 11:42:33 · certificado DOP — Pecorino Romano · insertó operativa de muelle, sede Costa Norte.COD_VERSION = 2—VALID_FROM18-mar-2026 11:42:33 ·VALID_TO31-dic-9999 (abierta) · certificado NO DOP — pecorino de pasto · insertó carga automática del laboratorio.
Y ahora la pregunta del viernes tiene respuesta sin fricción.
¿Qué creía el modelo el 14 de marzo? La fila vigente ese día: versión 1, certificado DOP. ¿Qué cree hoy? Versión 2, NO DOP. Las dos respuestas son ciertas en su ventana, y las dos vienen del mismo modelo, sin tocar nada, sin reproyectar logs, sin reconstruir desde copias. La misma consulta — solo cambia el filtro temporal.
Lo que hace este patrón especial es que el versionado vive dentro del modelo, no encima. No hay una herramienta externa que registra qué pasó cuándo. La estructura del aparato es el registro. La memoria es propiedad estructural, no propiedad procedimental. Y las propiedades estructurales sobreviven a la rotación del personal, a los cambios de proveedor, a las reorganizaciones de equipos. El procedimiento se olvida; la estructura no.
Pero versionar nativamente es solo la mitad de la historia. La otra mitad — la que cierra el pilar Federated Computational Governance entero — vive en cómo se usa esta memoria cuando hay que volver al pasado. Y eso cierra el martes que viene.
Lo que viene
Esa es la propiedad estructural. Lo que falta — y lo que cierra el pilar — es la doctrina que sale de ella: qué significa reproducir el pasado contra la regla del momento, y cómo la fábrica demuestra que no sabía lo que no podía saber.
El martes que viene: cinco sedes, 371 pizzas, 70 clientes con factura nominativa. Una consulta. Sin proyecto. Y al fondo de la cocina central, la pizarra del lunes a las nueve con el listado del lote y una frase debajo escrita con tiza que cualquier persona del sector — sin contexto técnico, sin haber leído ningún Pulse anterior — entendería de inmediato.
Hasta el martes.